Data center management

ABSTRACT

Provided is a process of managing rack-mounted computing devices in a data center with a distributed peer-to-peer management system, the process including: determining roles of data-center management computing devices in a distributed peer-to-peer data-center management system; receiving, via an out-of-band network, a data-center management command at a given data-center management computing device; distributing, based on at least some of the roles, via the out-of-band network, the data-center management command.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation-in-part of U.S. patentapplication Ser. No. 15/065,212, titled OUT-OF-BAND DATA CENTERMANAGEMENT VIA POWER BUS, filed 9 Mar. 2016, which claims the benefit ofthe following U.S. Provisional Patent Applications: U.S. 62/130,018,titled RACK FOR COMPUTING EQUIPMENT, filed 9 Mar. 2015; U.S. 62/248,788,titled RACK FOR COMPUTING EQUIPMENT, filed 30 Oct. 2015; and U.S.62/275,909, titled RACK FOR COMPUTING EQUIPMENT, filed 7 Jan. 2016. Theentire content of each parent application is incorporated by referencein its entirety.

BACKGROUND

1. Field

The present invention relates generally to computing equipment and, morespecifically, to management networks for data centers.

2. Description of the Related Art

Data centers are often used to house and interconnect large collectionsof computing devices, like servers, databases, load balancers, andhigh-performance computing clusters. Often, the computing devices areinterconnected with two different networks: 1) an in-band network forconveying the data upon which the computing devices operate, forexample, content in webpages, queries and query responses, and data forhigh-performance computing; and 2) an out-of-band management network forconveying commands to the individual computing devices to manage theiroperation, e.g., for conveying information like sensor data indicativeof the operation of the computing devices or for remote serial consolesessions for server management.

Out-of-band management serves a number of purposes, depending on thecontext. Often, out-of-band management networks are used to managesecurity risk, by limiting the attack surface of a network that could beused to control the computing devices and segregating the in-bandnetwork that often receives data from the outside world. In some cases,out-of-band management networks are operative to control the computingdevices even when the computing devices are turned off, for example, byaccessing memory on computing devices that is persistent (like flashmemory) to perform things like extensible firmware interface (e.g., BIOSor UEFI) updates, read values from registers indicative of configurationor state, and the like. Other examples of activities include booting adevice that is been turned off, remote installation of operatingsystems, updates, setting hardware clock speeds, updating or queryingfirmware versions, and the like.

SUMMARY

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

Some aspects include a process of managing rack-mounted computingdevices in a data center with a distributed peer-to-peer managementsystem, the process including: determining roles of data-centermanagement computing devices in a distributed peer-to-peer data-centermanagement system; receiving, via an out-of-band network, a data-centermanagement command at a given data-center management computing device;distributing, based on at least some of the roles, via the out-of-bandnetwork, the data-center management command from the given data-centermanagement computing device to a first plurality of other data-centermanagement computing devices; and for each of the first plurality ofother data-center management computing devices, distributing, based atleast some of the roles, via the out-of-band network, the data-centermanagement command to a respective second plurality of other data-centermanagement computing devices, wherein: the given data-center managementcomputing device, the first plurality of other data-center managementcomputing devices, and the respective second pluralities of otherdata-center management computing devices are each configured to manage arespective plurality of rack-mounted computing devices; each of thepluralities of respective rack-mounted computing devices executes anin-band application that communicates on an in-band network differentfrom the out-of-band network; and the data-center management command isa command to update or otherwise configure a microkernel, a virtualmachine, a container, an operating system, or an application executingon one or more data-center management computing devices.

Some aspects include a tangible, non-transitory, machine-readable mediumstoring instructions that when executed by one or more processorseffectuate the above process.

Some aspects include one or more processors and memory storinginstructions that when executed by the processors effectuate the aboveprocess.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following figures in which like numbers indicate similar oridentical elements:

FIG. 1 is a physical-architecture block diagram that illustrates a datacenter configured for out-of-band management via power bus, inaccordance with some embodiments;

FIG. 2 is a physical-architecture block diagram that illustrates a datacenter configured for out-of-band management without using a power busfor communication, in accordance with some embodiments;

FIG. 3 is a physical-and-logical-architecture block diagram thatillustrates a data center configured for out-of-band management withoutusing a power bus for communication and with a rack controller executedby a managed device, in accordance with some embodiments;

FIG. 4 is a physical-and-logical-architecture block diagram thatillustrates a data center configured for out-of-band management via apower bus and with a rack controller executed by a managed device, inaccordance with some embodiments;

FIG. 5 is a flow chart that illustrates an example of a process forout-of-band management of a data center, in accordance with someembodiments;

FIG. 6 is a flow chart that illustrates an example of a process tomanage rack-mounted computing devices, in accordance with someembodiments;

FIG. 7 is a block diagram of a topology of a data center managementsystem, in accordance with some embodiments;

FIG. 8 is a flow chart that illustrates an example of a process executedby the system of FIG. 7 to manage a data center, in accordance with someembodiments; and

FIG. 9 is a diagram that illustrates an exemplary computing system bywhich the above processes and systems may be implemented, in accordancewith embodiments of the present techniques.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit theinvention to the particular form disclosed, but to the contrary, theintention is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of the present invention as definedby the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

To mitigate the problems described herein, the inventors had to bothinvent solutions and, in some cases just as importantly, recognizeproblems overlooked (or not yet foreseen) by others in the field of datacenter equipment design. Indeed, the inventors wish to emphasize thedifficulty of recognizing those problems that are nascent and willbecome much more apparent in the future should trends in the data centerindustry continue as applicants expect. Further, because multipleproblems are addressed, it should be understood that some embodimentsare problem-specific, and not all embodiments address every problem withtraditional systems described herein or provide every benefit describedherein. That said, improvements that solve various permutations of theseproblems are described below.

This patent disclosure describes several groups of inventions that canbe, but need not necessarily be, used together. The groups are describedin a sequence that generally follows their relative proximity to theedge of an out-of-band network or networks. A first group of inventionsdescribed with reference to FIGS. 1-4 and FIG. 5 relates to a system andprocess by which an out-of-band network may be implemented between arack-mounted computing device and a rack controllers or other datacenter management computing devices. A second group of inventionsdescribed with reference to FIGS. 1-4 and FIG. 6 relates to systems andprocesses for managing groups of rack-mounted computing devices withrack controllers and other data center management computing devices. Athird group of inventions described with reference to FIGS. 1-4 andFIGS. 7 and 8 relates to systems and processes for managing groups ofrack controllers and other data center management computing devices.Additional inventions described take the form of combinations of thesegroups.

Many extant out-of-band management products have deficiencies. Amongthese problems, the application program interface (API) capabilities ofthese products are lacking. Additionally, many existing out-of-bandmanagement products rely on a wired, Ethernet-based communications busand some variation of a baseboard management controller (BMC) perserver. As a result, many of these systems suffer from reliance on anAPI that is difficult to implement, sensorfication that is typicallylimited to chassis-only (e.g., on the chassis of the rack-mountedcomputing device, rather than on the rack itself or relatedinfrastructure), and reliance on wired connections and a BMC, which mayhave a more limited set of exposed functionality than some embodiments.

Additionally, many data center management products also lack the abilityto sufficiently aggregate and analyze data across a multitude ofservices, including application, operating system, network, buildingmanagement system, hardware, power, fire, and other capabilities. Theability to look “north” and “south” of the rack is an open issue in thedata center market. Typically, significant hardware investment has beennecessary to achieve modest monitoring and control capabilities; theability to provide northbound and southbound management and analyticscapabilities in a variety of form factors (controller, switch module,etc.) has been hard to achieve.

Generally, there is a need for a turn-key, easy-to-operate set ofmanagement, sensorfication and intelligence services that arewell-integrated with hardware like that described herein and used indata centers. This includes supported power, fire, network, and otherancillary equipment, in some embodiments. (This is not to suggest thatsome embodiments do not also suffer from different subsets of theabove-described issues, as the various inventions described herein maybe used to beneficial effect without implementing other inventionsaddressing other problems. Thus, not all embodiments mitigate alldescribed problems, and some embodiments mitigate problems implicitlydescribed that will be apparent to one of ordinary skill in the art.)

In some embodiments, a Data Center Sensorfication, Control, Analyticsand Management Platform, referred to as “Vapor CORE,” mitigates some orall of the problems above by providing a set of services withsouth-of-rack (‘southbound’) management and monitoring capabilities, aswell as north-of-rack (‘northbound’) aggregation and analyticscapabilities. In some embodiments, these capabilities are exposed in a‘southbound’ API and ‘northbound’ API, and are supported by a variety oftools and deployment options that can be used to integrate, analyze,visualize and operationalize the data and decisions generated by theAPIs and components. In some embodiments, Vapor CORE's API may beexposed by rack control units or other data center management computingdevices, like those described below and that execute logic to implementthe APIs.

In some embodiments, Vapor CORE is implemented as a set of microservices(e.g., each executing a server monitoring a respective port on arespective computing device and executing code responsive tocommunications received via that port (either loopback or external) andsending output via that port), executing on the rack controllerdescribed below, and deployed and managed automatically by thetechniques described below or those the Crate Configuration, Containerand File management system described in U.S. patent application Ser. No.62/275,909, filed 7 Jan. 2016, titled RACK FOR COMPUTING EQUIPMENT, thecontents of which are incorporated by reference above. The services maybe organized in two categories: a southbound API and a northbound API.

The southbound API of Vapor CORE, in some embodiments, provides aRESTful (representational state transfer) API built atop Nginx™ anduWSGI™, using Flask™ as the microdevelopment framework. A Python™package, in some embodiments, is used to interpret API requests andtranslate them into a serial protocol payload, sent over power linecommunications (PLC) to devices along the serial bus. Response data, insome embodiments, is read from the serial bus, interpreted, and returnedto the API consumer in JSON format. The API capabilities, andcorresponding implementing code, in some embodiments, include:

Ability to scan or enumerate the devices to gather a full picture ofdevices and capabilities available; the results of the scan, in someembodiments, are returned in an easy-to-interpret form that allows foreasy programmatic access. These results, in some embodiments, alsoinclude locational information for sensors and devices, for easy mappingand visualization of every piece of data gathered from the system, asdiscussed in U.S. patent application Ser. No. 15/337,732, filed on 28Oct., 2016, titled SENSING LOCATION OF RACK COMPONENTS, the contents ofwhich are hereby incorporated by reference, and elsewhere in thisdocument with reference to location-awareness-related sensing.

Reading of analog and digital sensors. This, in some embodiments,involves translating a stream of bytes into a meaningful andhuman-understandable response. Sensor support, in some embodiments,includes humidity, temperature, pressure, vibration, particulate, noise,and other similar sensors.

LED (light emitting diode) control for rack (e.g., wedge) statuscommunication. The LED light at the top of a rack, in some embodiments,may be changed in terms of color, illumination, or blinking to visuallycommunicate rack status. Or audible or other visual indicators may beactuated.

Fan control, including, in some embodiments, getting fan status in termsof revolutions-per-minute (RPM).

Power control and status. This involves, in some embodiments, sending acommand to a device, requesting power on/off/cycle or status. In somecases, power status is returned and translated from the power supply'sformat to a more easily machine- or human-interpretable form. This, insome embodiments, includes power status (on/off), power “ok”(true/false), voltage and current consumption, and whether the powersupply registers an undervoltage or overcurrent condition.

Device inventory, including subcomponent inventory from servers anddevices in the rack. The response, in some embodiments, may also includeExtensible Firmware Interface (EFI) (like Basic Input/Output System(BIOS) or Unified Extensible Firmware Interface (UEFI)) information,which may include items such as Asset Tag and other device-specificinformation.

Boot device selection, allowing, in some embodiments, boot device to beretrieved from device, as well as for the boot target to be specified.This, in some embodiments, may be used for automated provisioning ofdata center devices.

Door lock control. Door locks, in some embodiments, may be controlled ona rack's front door to allow/deny physical access to rack contents, aswell as to provide an audit trail of physical access to a given rack. Orsome embodiments may implement U-specific locks that gate access toindividual rack-mounted computing devices.

Intelligent Platform Management Bus (IPMB) Communications Protocol. Someembodiments allow sending/receiving of IPMB packets over serial bus tocarry out standard IPMI commands over IPMB via a powerline communication(PLC) bus.

OCP (Open Compute Project™) debug header POST (power-on self-test) coderetrieval.

Firmware flash. Some embodiments allow device firmware to be remotelyupdated through the API.

Version information about the endpoint, software, and API.

Additionally, in some embodiments, the southbound services provided byVapor CORE include serial console access to individual devices in therack. This access, in some embodiments, is provided over PLC as well,and is mapped to virtual TTY devices, that may be accessed locally fromthe rack controller described below, or remotely via secure shell (SSH)to a Transmission Control Protocol (TCP) port on the rack controllerdescribed below. This, in some embodiments, is implemented by mapping aTTY to a device ID, and communicating with rack controller describedbelow to marshal access to the serial console of that device.

The services described above, in some embodiments, are distributed via aDocker™ container, managed by Crate (described below with reference toFIGS. 1-4 and 7-8). Serial console access, in some embodiments, ismanaged by a separate operating system module that scans the bus andcreates and maps the devices based on its interpretation of the scancommand.

In some cases, the southbound API may facilitate the process ofobtaining data from sensors on rack-mounted devices, like servers.Often, sensors impose a large number of steps to convert sensor readingsto things useful to machines or humans, e.g., converting a voltage froma thermocouple to a temperature. To mitigate this issue, someembodiments may identify what type of sensor is present based on a codereturned that indicates the sensor type, which may be obtained based onelectrical characteristics and reading registers, for instance, usingtechniques described below or in U.S. patent application Ser. No.62/275,909, in a section titled “External Access to Local MotherboardMonitoring and Control.” In some embodiments, based on the code, theappropriate conversion may be selected, e.g., volts to degrees Celsius.Some embodiments may use this technique to obtain temperature, humidity,particulate count, air flow rates, etc., as opposed to a voltage or acurrent or other scaled value.

The northbound side of Vapor CORE, in some embodiments, is a separatemicroservice that is designed in a three-level pluggable architectureincluding the following:

Data source plugins

Analytics engine

Presentation plugins

Data source plugins, in some embodiments, may be registered with VaporCORE given a standard data source data transformation API and may beused to gather data from a variety of sources in the data center,including, in some embodiments, the southbound API, Crate, buildingmanagement systems, fire suppression and power distribution systems,Bloom box API™, other management and control systems (e.g., Puppet™,Chef™, Ansible™, etc.), IPMI/iLO/DRAC, etc. Registration of components,in some embodiments, includes storage of addressing, credentials andrules for polling, among other things; registration data piggybacks thedata store in the analytics layer, and may be carried out via API oruser interface (UI) (both distributed with Vapor CORE).

In some embodiments, an analytics engine component serves as a primarydata store for Vapor CORE and stores plugin registration, as well asschematized data gathered by plugins. Pre-built analytics routines, insome embodiments, may be included with Vapor CORE to compute metricssuch as price per watt per dollar (price/W/$), cost of cloud, etc.Additional analytics routines, in some embodiments, may be developed bycustomers or solution vendors, and snapped into the analytics engine,bound to the data source plugins registered with Vapor CORE.

Presentation plugins (e.g., executing on a data center managementcomputing device, like those described below, for instance in adashboard application), in some embodiments, may be registered withVapor CORE given a standard presentation plugin API and may be used toexport the result of analytics routines in a variety of forms (e.g. UI,comma separated values (CSV), JavaScript™ Object Notation (JSON),extensible markup language (XML), etc.). Presentation plugins, in someembodiments, are bound to a set of analytics routines and data sourcesstored in the analytics engine, and transform and present the data in avariety of ways. Presentation plugins, in some embodiments, areregistered in a similar manner to data source plugins, and theirregistration also includes configuration of the output mechanism (e.g.TCP port, file, etc.).

In some embodiments, Vapor CORE sits atop a variety of data sources andprovides an endpoint exposing raw, aggregate and computed data pointsthat may be consumed by a higher level tool, such as an orchestration orautomation engine, dashboard, or as a data source input to another VaporCORE instance. Crate and Vapor CORE, in some embodiments, may alsocommunicate reciprocally to inform and perform automated managementtasks related to data center equipment or Vapor components such as VaporEdge Controllers (VECs) and Vapor software.

Vapor CORE, in some embodiments, may exist in a hosted environment, andbe used to remotely monitor and manage a data center, as describedelsewhere herein with reference to Crate.

In some embodiments, Vapor CORE may perform or provide critical (whichis not to imply that it, or any other feature, is required in allembodiments) environment live migration, data center management ordevops capabilities, workload and management capabilities and the like.

In some embodiments, the distributed nature of Vapor CORE and the datacenter racks may allow for strategies for data aggregation and analysisin a decentralized manner. This is expected to allow for the computingresources of the rack controllers to be well-utilized and facilitateoperations at scale.

Some embodiments may be configured to obtain a device inventory and bootselection from rack-mounted devices. For instance, upon scanning (e.g.,an inventory scan for a particular device), some embodiments may accessa system management bus (SMBUS) on the server midplane and retrieve alist of processors and device list seen by the operating system of theserver. In some cases, this data may be acquired from SMBUS withoutusing an agent executing within the operating system or on the CPU ofthe server. Similarly, some embodiments may access this bus tointerrogate and change boot target selection or adjust BIOS (or otherEFI) settings in memory, e.g., for automated provisioning that includesswitching to a different boot target on the network to roll out a newBIOS. In some embodiments, the boot target can be read and set by thesouthbound API, e.g., with a representational state transfer(REST)-based request. Further, some embodiments may perform agentlesssystem monitoring of the operation of the rack-mounted device, e.g.,tracking a server's CPU usage rate and memory consumption, in somecases, without using a BMC. Further, some embodiments may provide forremote console access—remote TTY—over powerline communication. In somecases, because communication occurs via a web proxy, web-based securitytechniques may be employed, like OAuth and Lightweight Directory AccessProtocol (LDAP).

In example use cases of some embodiments, these techniques may be usedto view diagnostic information describing a boot operation. Forinstance, if a machine is power cycled, some embodiments may retrievepower-on self-test (POST) codes for troubleshooting. These techniquesare best understood in view of an example computing environment.

In some cases, the features of Vapor Crate are provided by some of theembodiments described below with reference to FIGS. 1-5 and 7-8, thefeatures of Vapor CORE are provided by some embodiments described belowwith reference to FIGS. 1-4 and 6.

FIG. 1 illustrates a data center 10 configured to mitigate a variety ofproblems, both those explicitly discussed below, and those implicit inthe description and which will be apparent to those of ordinary skill inthe art. In some embodiments, the data center 10 includes a plurality ofracks 12 (e.g., identical racks arranged in a pattern, like arectangular array or hexagonal packing pattern), examples of which aredescribed in each of the applications incorporated by reference, such asthose titled RACK FOR COMPUTING EQUIPMENT. These applications describe,in certain embodiments, wedge-shaped racks arranged to form chambers,and those wedges may serve as the racks herein. Or the racks may takeother forms, e.g., traditional racks, e.g., those with hot aisles,arranged edge-to-edge along linear aisles, either with front-access orrear-access for maintenance.

The racks may house (e.g., mechanically support, cool, and provide dataand power to) a plurality of rack-mounted computing devices 13, anexample of which is described below with reference to FIG. 9. In someembodiments, the data center 10 includes a relatively large number ofracks 12, for example, more than 10, or more than 20, and each rack mayhouse a relatively large number of computing devices 20, for example,more than 10, and in many cases, more than 50. In some cases, therack-mounted computing devices 13 are arranged in discrete units ofspace, called “U's,” for instance in a vertical stack of U's. In somecases, the rack-mounted computing devices are mounted to rails (e.g., ona slideable shelf) and can be slid horizontally outward from the rackfor service. Or in some cases, the racks have U's arrayed horizontally,and rack-mounted computing devices 13 may be slid vertically, upward,like out of a bath of cooling liquid, such as mineral oil. In somecases, a cooling fluid (e.g., liquid or gas) is conducted over therack-mounted computing devices 13 for cooling. Three racks 12 are shown,but embodiments are consistent with a single rack or substantially moreracks. Each rack 12 may include the features illustrated in the enlargedview of one of the racks 12.

Data centers provide and use computational resources (e.g.,applications, networks, computing devices, virtual machines, containers,and the like) in two domains: (i) to provide general purpose computingpower (or special purpose computing power) to a user; and (ii) to managethe data center itself. Accordingly, it is helpful to define terminologyto distinguish between these domains, as commercial implementationsoften use different types of resources in each domain, typically withmuch less expensive and much less powerful resources being used formanagement. These different domains are distinguished herein by morebroadly leveraging the “in-band” and “out-of-band” modifiers used inindustry to identify networks serving these respective domains. Thus,the rack-mounted computing devices 13 may execute “in-band” applicationsthat provide the functionality for which a data center or rack thereinis built, e.g., hosting user-facing software-as-a-service applicationsor virtual machines, storage, or containers provided as service toremote users or applications. This is distinct from “out-of-band”resources (applications, computing devices, and networks) used to managethe rack-mounted computing devices 13, as part of the infrastructure ofa rack or (i.e., and/or) data center. In some embodiments, theout-of-band networks have less than ½ the bandwidth of the in-bandnetwork, e.g., less than 1/10th. In some embodiments, the out-of-bandcomputing devices (or corresponding constructs, like virtual machines)have less than ½ the available floating-point-operations-per-second thanthe in-band computing devices, e.g., less than 1/10th. Some embodimentsmay keep these out-of-band infrastructure resources and in-bandapplications separate, either partially (e.g., with different containersor virtual machines) or fully (e.g., with different computing devices),for security purposes.

To this end and others, some embodiments may include an in-band-network15 (e.g., implemented with network switches 11, like top-of-rackswitches) and an out-of-band network 17, each having a distinct addressspace (e.g., a private Internet-Protocol (IP) subnet or different rangesof public IP addresses), with the former 15 conveying data betweenrack-mounted computing devices 13 or the public Internet 19, and thelatter 17 conveying data within the data center 10 (and in some cases,externally) for purposes of managing the rack-mounted computing devices13 (e.g., monitoring, provisioning, load-balancing, updating, servicing,etc.) and related infrastructure (e.g., monitoring, responding to, andadjusting cooling or power delivery). Keeping the networks 15 and 17(and related computing devices or applications) separate is expected toreduce the likelihood of a penetration of the more externally facingin-band-network 15 resulting in an attacker gaining control of datacenter infrastructure. That said, embodiments are also consistent withconsolidating these networks or different subsets of the out-of-bandresources (e.g., computing devices or applications).

Many traditional out-of-band networks present a number of problems indata center designs. For instance, often switching and wiring isreplicated relative to the in-band-network all the way to the edge ofthe out-of-band networks, often doubling the networking equipment costsand wiring complexity in a data center (which should not be read as adisclaimer, as some embodiments of some inventions described herein areconsistent with this approach).

These problems often co-occur with other undesirable aspects of datacenter hardware. Additional issues include added cost for powerdistribution and conditioning circuitry. In many cases, power isdistributed within a data center via alternating current, whileindividual computing devices generally operate on direct current. Inmany cases, the transition between alternating current and directcurrent is made with computing-device specific AC-to-DC powerconverters. This architecture has the undesirable effect of multiplyingthe number of power converters within a data center, placing a heatsource and electromagnetic radiation source near sensitive computingequipment, occupying valuable rack space, and multiplying the number oflocations were failures may occur in hardware. (These discussions ofproblems with traditional design should not be taken as disclaimers ofsubject matter, as several inventions are described, and they areindependently useful and may be used in environments where some problemspersist while others are addressed.)

To mitigate these issues, in some embodiments, an edge-portion of theout-of-band network may be replaced or supplemented with a plurality ofpowerline communication networks that deliver both data anddirect-current power to a plurality of rack-mounted computing devices.In some cases, each rack 12 may include a (e.g., one and only one, ormore than one) rack-specific powerline network, which may be aDC-powerline network 16. Or in some cases, an individual rack 12 mayinclude a plurality of powerline networks, or a powerline network mayspan multiple racks 12. Or in some cases, a rack 12 may have separatepower-delivery and sub-networks (relative to the out-of-band network 15extending throughout a data center).

Thus, some embodiments may include 1) an in-band-network 15; 2) a datacenter-wide out-of-band network 17; and 3) a plurality ofsub-out-of-band networks 16. Each sub-out-of-band network may have theirown address space distinct from each other and the data center-wideout-of-band network and in-band network 15 (e.g., each using the sameaddresses for different devices on different racks), and eachsub-out-of-band network may provide out-of-band network access formonitoring and controlling a plurality of rack-mounted computing devices13 (e.g., a full-rack) and sensors and other actuators associated withthe plurality of rack compute units 20 (e.g., associated with the rack).

To these ends and others, an alternating-current-to-direct-currentconverter 14 may deliver direct current to each of the racks 12 via abus 16 that also conveys data. In some embodiments, each rack 12 mayinclude its own dedicated converter 14 that services a collection ofcomputing devices on the rack, or in some cases several racks 12 mayshare a converter 14. In some embodiments, converter 14 includes arectifier, step down transformer, and low-pass filter operative todeliver, for example, to racks 12, direct current power. Rack-specificconverters are expected to segment the media for out-of-band datasignaling, reduce the number of users of the address space on the media,and permit simplified and less expensive circuitry for the devicescommunicating on the DC power bus, but embodiments are also consistentwith busses shared across racks. Having consolidated AC-to-DC convertersfor a collection of computing devices (e.g., a full rack) is expected toavoid the cost and thermal load arising from performing the conversionat each computing device with a dedicated converter, though embodimentsare also consistent with this implementation. Some embodiments may haveone AC-to-DC converters per plurality of rack-mounted computing devices13, e.g., one per rack, or one per collection of racks. In some cases,data may be conveyed via an AC powerline network.

In some embodiments, direct-current power is distributed throughout arack 12 via a direct current power bus 16. In some cases, thedirect-current power bus 16 includes two distinct conductors, forexample, carrying ground and a 12-volt or 48-volt potential with two andonly two conductors along a terminal portion of a path to a devicereceiving power and data at an edge of the sub-out-of-band networkformed by bus 16. In some embodiments, each rack 12 may include the DCbus 16, or a dedicated DC bus 16 specific to that rack, for example, tomaintain and address space within a rack that is distinct from that ofother racks and simplify signaling protocols (e.g., by reducing thenumber of devices contending for a given instance of the network medium)and reduce cost of associated circuitry.

In the illustrated embodiment, racks 12 each include a rack control unit18, a plurality of rack-mounted computing devices 13, a plurality ofsensors 21, and a plurality of actuators 23. The racks 12 may have aplurality of rack computing units 20, e.g., each being one U and havingone or more of the rack-mounted computing device 13 along withdevice-specific support hardware, like the adapters 30 described below.Two units 20 are illustrated, but embodiments are consistent withsubstantially more, for example, on the order of 8 or more per rack.Some embodiments may have multiple rack-mounted computing devices 13 perunit 20, or multiple units 20 per device 13.

In some embodiments, the rack control unit 18 is a type of data centermanagement computing device and, thus, may exercise local control andmonitoring (e.g., without directly monitoring or controlling devices inother racks—though embodiments are also consistent with this) over theoperation of devices 20, 21, and 23 in the rack 12 (and performoperations distinct from a network switch that routes in-band data), andeach rack 12 may include its own independent rack control unit 18. Inother cases, the data center management computing device may berack-mounted computing device executing a rack controller that exerciselocal control and monitoring (which is not to imply that monitoring isnot an aspect of or form of control).

In some embodiments, the rack control units 18 may operate as gatewaysbetween an Ethernet out-of-band network 17 and a DC power bus networks16, for example, specific to each rack 12. In some embodiments, the outof band Ethernet network 17 may connect each of the racks 12 via theirrack control unit 18, and the data center may be managed via networks 16and 17, with monitoring data being sent back to a data center managementcomputing device 25 via networks 16 and 17 and commands beingdistributed via network 17 for implementation by controllers 18 andnetworks 16.

Sensors 21 may be any of a variety of different types of sensors, likethose described below as being associated with rack computing units 20.Examples include temperature, particulate, vibration, humidity, optical,and other sensors. In some cases, the sensors 21 are secured to the rack12 itself, rather than a computing unit 20 or device 13 (e.g., thedevice 13 can be removed and the sensor 21 would remain on the rack, andthe sensor 21 may be on the rack before any devices 13 are installed).In some cases, the sensors 21 are not specific to an individualcomputing unit 20 or device 13. Or some embodiments may include, as partof the rack 12, one or more sensors for each U in the rack 12, e.g., alocation sensor like those described in U.S. patent application Ser. No.15/337,732, filed 28 Oct. 2016, titled SENSING LOCATION OF RACKCOMPONENTS, the contents of which are incorporated by reference.

In some cases, the sensors 20 sense an attribute of the rack and itsenvironment and send signals indicative of measurements via network 16to controller 24. In some cases, some sensors 20 are based onmicrocontrollers rather than full computers (having an operating systemexecuted on a microprocessor) to sense and report values withoutincurring the cost and thermal load associated with a full computer(though embodiments are also consistent with this approach).

Actuators 23 may have features similar to the sensors 21 in the sensethat some are microcontroller-based, some are distinct from units 20 anddevices 13, and some draw power from the network 16 for similar reasons.In some cases, the actuators 23 are controlled by the rack control unit18, e.g., reporting via network 16 a physical state of the sensor,receiving a command to change that state via network 16, and effectingthe change with power from the network 16. A variety of different typesof actuators may be included. Examples include a fire-suppressionactuator operative to release a fire-suppression chemical (e.g., a gasor foam). Other examples include an actuator operative to adjust coolingfluid flow (e.g., a solenoid configured to cause rotation or translationof components of the spatially modulated airflow restrictors describedin U.S. patent application Ser. No. 15/065,201, filed 9 Mar. 2016,titled COOLING SYSTEM FOR DATA CENTER RACK, the contents of which arehereby incorporated by reference) in a selected part or all of a rack(like responsive to a fire being detected to remove airflow orresponsive to a temperature sensor in a rack indicating higher-localtemperatures). For instance, some embodiments may detect a highertemperature in an upper part of one rack with a sensor 21 than a lowerpart, and with controller 18, instruct an actuator 23 to adjust a ventto afford greater airflow in the upper part or restrict airflow in thelower part (or other fluids). In another example, some embodiments mayinclude a locking actuator, e.g., a pin driven by a solenoid biased openor closed by a spring into an aperture in an otherwise moveablecomponent, and the lock may lock a given computing unit 20 shelf inplace or a rack door closed, thereby providing physical security. Insome cases, a sensor on the face of a rack may include anear-field-communication (NFC) sensor by which a technician's NFC card(or mobile device) is scanned to authenticate access, thereby limitingphysical access to those authorized and providing an audit trail for whoaccessed what when.

In some cases, the sensors 21 and actuators 23 may be powered by andcommunicate with the network 16. Having distributed DC power and networkcommunication available is expected to facilitate the use of denser andmore widely distributed networks of sensors and actuators than isfeasible in traditional designs in which each sensor would need its ownAC-to-DC power source and an Ethernet network interface, adding cost andthermal load (though not all embodiments afford this benefit, which isnot to imply that other features may not also be varied). In some cases,sensors 21 and actuators 23 may be operative without regard to whether arack computing unit 20 is present or on, thereby providing sensing andcontrol that is robust to crashes or lower-density deployments.

In some embodiments, remote terminal sessions, for example, may bemaintained between the administrator's computer 25 connected to network17 and individual rack computing units 20 via networks 17 and 16. Insome embodiments, rack control units 18 may monitor the operation andpresence of rack computing units 20 and, in some cases, components ofthose rack computing units 20, via the powerline communication bus 16.In some embodiments, the rack control unit 18 may be configured toperiodically poll existing devices on the network 16 and report back vianetwork 17 the result of the poll to device 25. In some cases, rackcontrol units 18 may periodically request, from each rack computing unit20 via the DC power bus 16, the status of various sensors, such astemperature sensors, vibration sensors, particulate sensors, fan speedsensors, airflow sensors, humidity sensors, air pressure sensors, noisesensors, and the like. In some embodiments, rack control unit 18 maycompare the reported values to a threshold and raise or log variousalarms, for example, via network 17, to bring a condition to theattention of an administrator. Similarly, in some cases, rack controlunit 18 may implement various changes on rack computing units 20 by acommand sent via network 16. Examples include instructing rack computingunits to boot up or turn off, update an EFI, change a setting inpersistent flash memory (in some cases bypassing the EFI), update orreport a firmware version, change a register value in a peripheral, andinitiating and executing a remote terminal session. In some embodiments,rack control unit 18 and network 16 are operative to exercise controlover the rack computing units 20 even when the computing devices, suchas servers of those rack computing units, are turned off. This isexpected to reduce the burden on maintenance personnel, as certainoperations can be performed remotely, even in scenarios in which thecomputing devices are turned off

In some embodiments, rack computing units 20 each occupy a respectiveshelf or a receptacle, such as a “U,” in the rack. In some embodiments,each rack computing unit includes a distinct computer, having adedicated processor and memory that operates to execute an operatingsystem and application within a distinct memory address space. Any of avariety of applications may be executed, including web servers,databases, simulations, and the like, in some cases in virtualizedcomputing devices or containers. In some cases, the rack-mountedcomputing devices 13 in each unit 20 are general purpose computers, orsome embodiments may include special purpose computers, such asgraphical processing units, bitcoin mining application specificintegrated circuits, or low-floating-point precision (e.g., less than 16bit) ASICS for machine learning. In some embodiments, the applicationsmay communicate with one another and remote users via the in-bandnetwork 15 that conveys the data the computing devices operates upon,which stands in contrast to the management data by which the computingdevices are managed and monitored via the out-of-band network 17.

In the illustrated embodiment, rack control unit 18 includes a rackcontroller 24, and out-of-band network interface 26, and a powerlinemodem 28. In some embodiments, the rack controller 24 may implement thelogical functions described above and below, for example, for monitoringthe rack computing units 20 and sensors 21, controlling the rackcomputing units 20 and actuators 23, and translating between thenetworks 16 and 17. In some embodiments, the rack controller 24 mayexecute routines that control, engage, and disengage various thermalcontrol units, such as fans or adjustable airflow restrictors, thatmaintain the temperature of the rack computing units 20, for example,responsive to temperature sensors on the units 20 indicating animbalance in airflow or positive pressure in an exhaust region. In someembodiments, the rack controller 24 is an application executing on adistinct computing device having a processor, memory, and an operatingsystem, and such as a computer serving as the rack control unit 18without hosting in-band applications, e.g., one provided with the rack12 before in-band computing devices are installed. In some embodiments,the rack controller 24 includes a REST-based web server interfaceoperative to receive instructions and provide responses on the network17 according to a RESTful API. In some cases, the REST-based API mayface the out-of-band network 17, receiving API requests via this networkfrom other rack control units 18 or the administrator computing device25.

In some embodiments, the out-of-band network interface 26 is an Ethernetnetwork interface having an associated driver executing in the operatingsystem of the rack controller 24 and configured to move data betweenbuffer memory of the network interface and system memory, e.g., withdirect memory access, and provide interrupts indicative of suchmovements. In some cases, the out-of-band network interface 26 connectsto an Ethernet cable, such as a CAT5 (category 5), or CAT6 (category 6)cable connecting to the other racks 12.

In some embodiments, the various devices on the DC power bus 16,including the rack control unit 18, include a powerline modem 28. Insome embodiments, the powerline modem 28 is a direct current powerlinemodem operative to encode data on top of a direct current power source.(Signals readily separated from the DC power, e.g., at higher than athreshold frequency or less than a threshold root-mean-square deviationfor the median, do not transform the DC power to AC power.) In someembodiments, the data is transmitted by applying an electrical stimulusto the electrical conductors conveying direct current power. Thestimulus may take any of a number of different forms. Examples includeselectively connecting a higher or lower voltage to the conductors,thereby pulling the voltage up or down in a manner that may be sensed byother powerline modems. Other examples include selectively connecting acurrent source or drain to the conductors of the DC power bus 16,thereby again imparting an electrical signal on top of the DC power thatmay be sensed by other computing devices. In some embodiments, animpedance may be selectively coupled to the DC power bus, thereby, forexample, affecting fluctuations imposed on top of the DC power bus in amanner that may be sensed by other powerline modems.

In some embodiments, the electrical stimulus is a time varyingelectrical stimulus. Data may be encoded by varying the electricalstimulus a number of different ways. In some embodiments, the stimulusmay simply be turned on and off according to a clock signal, like with asquare wave, and data may be conveyed by determining during each clockcycle whether the stimulus is applied or not, indicating a zero or one.In other examples, the stimulus may be used to adjust an attribute of awave, like a carrier wave, maintained on the DC power bus. For example,data may be encoded with pulse width modulation, by applying a squarewave to the DC power bus and adjusting the time of a falling edge of thesquare wave according to whether a zero or one is being transmitted.Other examples may adjust a rising edge of the square wave or a dutycycle of the square wave or other waveforms. In some embodiments,multiple attributes may be adjusted, for example varying in amplitude ofthe wave, a duty cycle of the wave, and times for falling or risingedges of the wave to encode additional data in a more compact form.

In some embodiments, at the same time data is being conveyed on the DCpower bus, DC power is also being conveyed. In some embodiments, thedata signals may be configured such that they do not interfere with thedelivery of DC power. For example, the time varying electrical stimulusmay change the DC voltage or current by less than a threshold percentageof what is delivered, for example with a RMS value less than 10% of themedian, such that filtering can readily remove the data signal fromelectrical power being delivered to computing devices that are oftensensitive to variations in electrical power. In other embodiments, thespeed with which the data is conveyed, or a carrier wave, may be at afrequency such that low-pass filters can readily distinguish between theDC power component and the data component.

In some embodiments, to facilitate separation of data from power, thedata may be encoded with pulse width modulation, such thatdata-dependent effects are less likely to interfere with power delivery.For example, absent a carrier wave, a relatively long string of ones orzeros that are consecutive may cause power to fluctuate on thedownstream side of a low-pass filter, resulting in low-frequencyincreases or decreases in voltage of the DC powerline that may penetratea low-pass filter. In contrast, pulse width modulation maintains arelatively uniform average voltage after a low-pass filter is applied,as the frequency of the pulses that are modulated may be selected suchthat they are readily separated from the underlying DC power signal.

In some embodiments, access to the DC power bus as a medium for datatransmission may be arbitrated with a variety of techniques. Examplesinclude time division multiplexing, code division multiplexing,frequency division multiplexing, orthogonal frequency-divisionmultiplexing, and the like. In some implementations, it is expected thatthe bandwidth requirements for the network 16 will be very low (e.g.,less than 100 kilobits per second), and an encoding scheme may beselected to reduce the cost of the associated circuitry. For example, insome implementations, the speed and cost of Ethernet connections may beexcessive relative to the requirements for signaling. In contrast,relatively low bandwidth time division multiplexing circuitry on asynchronous network is expected to cost substantially less while stillproviding adequate bandwidth. This is not to suggest that embodimentsare inconsistent with higher bandwidth architectures. It should be notedthat many in the industry have persistently failed to recognize thisopportunity for cost reduction and circuitry simplification.

In some embodiments, each powerline modem 28 may select a duration oftime over some cycle in which that powerline modem on the network 16 ispermitted to transmit, e.g., in the event that the powerline modem doesnot detect that another device on the network currently has control ofthe media. In some embodiments, a device has control of the media if ithas received a request on the network 16 and has not yet responded. Insome embodiments, the network may be a synchronous network. In someembodiments, the duration of time dedicated for each powerline modem onthe network 16 to transmit when the media is unclaimed may be selectedbased on a factory set value, like a media access (MAC) address,initially.

In some embodiments, an ad hoc mechanism may be used to deal withcollisions, in which multiple devices have selected the same duration oftime. In some embodiments, the powerline modem 28 may be operative todetect when another device is transmitting at the same time, and inresponse, select a different duration of time, for example, randomly(like pseudo-randomly or by seeding a linear shift register with lesssignificant digits of a reading from a temperature sensor). Forinstance, powerline modem 28 may have reserved as its time to transmitbetween zero and 100 milliseconds (ms) after some timing signal, while apowerline modem of a first rack control unit may have reserved as itstime to transmit 100 ms to 200 ms, and a different rack computing unitmay have as its time to transmit 300 ms to 400 ms. Collisions occur whentwo devices select the same duration of time, and a randomizedre-selection may alleviate the conflict without a central authorityallocating time slots. Selecting transmission durations in an ad hocfashion is expected to substantially lower the cost of maintenance andsimplify installation, as devices can be installed on the network 16without additional configuration, in some embodiments. That said, notall embodiments provide this benefit, as several inventions aredescribed that are independently useful.

In some embodiments, the modem 28 may encode data and commands in aparticular format, for example, in packets having headers with anaddress of the receiving and transmitting devices. In some embodiments,each powerline modem on the network 16 may receive signals and determinewhether the signal includes a packet having a header designated for thatdevice. In some embodiments, the packets may include error correctionand detection, for example, with parity bits, Hamming codes, or otherredundant lower entropy encoding.

A variety of techniques may be used to receive signals. For example,some embodiments may apply the signal on the DC power bus 16 to alow-pass filter and then compare the filtered signal to the signal onthe DC power bus 16 to determine a differential signal having, forexample, a higher frequency component conveying data. In some cases, thedifferential may be compared to a threshold to determine whether a zeroor one is being transmitted. Or a pulse-width modulated signal may becompared to an unmodulated signal of the same underlying frequency, andchanges in edge timing may produce a signal that, when compared to athreshold, indicates a zero or one.

In some embodiments, the signals may correspond to those traditionallyused in RS232 connections to facilitate re-use of existing hardware andsoftware. Examples include the Data Terminal Ready signal, indicatingthat data terminal equipment (DTE) is ready to receive, initiate, orcontinue a call; the Data Carrier Detect signal, indicating a datacircuit-terminating equipment (DCE) is receiving a carrier from a remoteDCE; Data Set Ready, indicating that DCE is ready to receive commands ordata; Request to Send, indicating that a DTE requests the DCE prepare totransmit data; Request to Receive, indicating that a DTE is ready toreceive data from a DCE; Transmitted Data, carrying data from the DTE toDCE; and Received Data, carrying data from the DCE to the DTE.

In some embodiments, communication may be via request and response,where once a request is sent by one device on the network 16, therecipient device has the exclusive right to transmit on the network 16until a response is sent. Or some embodiments may use a master-slavearchitecture, where, for example, the powerline modem 28 of the rackcontrol unit 18 arbitrates which device communicates on the network 16and when. Request and response synchronous architectures, however, areexpected to allow for relatively simple and inexpensive circuitry, whichmay be favorable in some implementations.

As illustrated, in some embodiments, each rack computing unit 20 mayinclude a network and power adapter 30 and a rack-mounted computingdevice 13 (a term that is reserved herein for in-band computing devices(which may be hybrid devices that also execute out-of-band applicationsin some embodiments like those described with reference to FIGS. 3 and4)). In some embodiments, the network and power adapter 30 may separateDC power and data from the DC power bus 16, provide the power to therack-mounted computing device 13, and process the data to implementvarious routines locally with logic that is independent of therack-mounted computing device 13 and operates even when the rack-mountedcomputing device 13 is turned off.

In the illustrated embodiment, the network and power adapter 30 includesa low-pass filter 34, a powerline modem 36, and a microcontroller 38. Insome embodiments, these components 34, 36, and 38 may be mounted to aprinted circuit board that is distinct from a motherboard of therack-mounted computing device 13 and couples, for example, via a cable,to the motherboard of the device 13. In some embodiments, the low-passfilter 34 may be operative to receive the DC power from the DC power bus16, having the data signals overlaid there on, and remove the datasignals to transmit a smooth, high quality DC power source to therack-mounted computing device 13. A variety of techniques may be used toimplement the low-past DC filter 34. In some embodiments, an inductormay be placed in series between the bus 16 and the rack-mountedcomputing device 13 to provide a relatively large impedance therebetweenand reduce the power required to drive data signals onto the bus 16 andprotect associated driver circuitry. In other embodiments, the low-passDC filter 34 may also include a resistor placed in series between thebus 16 in the rack-mounted computing device 13, with a capacitor placedbetween a ground and high voltage signal of the bus to, again, providean impedance to reduce the power requirements to drive data signals,while smoothing fluctuations.

In some embodiments, the powerline modem 36 is substantially similar tothe powerline modem 28 described above and may implement the sameprotocols. In some embodiments, each rack computing unit 20 containssimilar or the same features.

In some embodiments, the microcontroller 38 is operative to receivesignals from the powerline modem 36 and take responsive action. In someembodiments, the microcontroller 38 monitors addresses in headers onpackets received via the powerline modem 36 and determines whether theaddress corresponds to the rack computing unit 20. In some embodiments,the address is stored in persistent flash memory of the microcontroller38, for example, in flash memory set with a serial number or MAC addressset at the factory. In some embodiments, upon initially detecting thatthe network and power adapter 30 is connected to a DC power bus 16, themicrocontroller 38 may broadcast is address to the other devices, forexample, to add the address to a list of addresses maintained by therack control unit 18 as received via the powerline modem 28.

In some embodiments, the microcontroller 38 may receive commands fromthe rack control unit 18 and implement those commands, for example, byquerying or otherwise polling various sensors, like those describedabove, to monitor things like resources being used by the rack computingunit 20 (e.g. processor usage or memory usage), or environmentalconditions, like temperature, vibrations, airflow, particulates,humidity, electromagnetic radiation, and the like. In some embodiments,the microcontroller 38 may be operative to drive various signals intothe rack-mounted computing device 13 that reconfigure the rack-mountedcomputing device 13, monitor the rack-mounted computing device 13, orcontrol the rack-mounted computing device 13. Examples include sendingsignals onto a system management bus or other bus of the rack-mountedcomputing device 13 that cause the rack-mounted computing device 13 toturn on, turn off, change a setting accessible via a BIOS (in some caseswithout engaging the BIOS and writing directly to flash memory),reconfiguring various settings, like clock speed or register settingsfor peripheral devices. In some embodiments, the microcontroller 38 isoperative to poll various sensors that indicate the location of the rackcomputing unit 20, for example, by reading a value with an opticalsensor or a radio frequency sensor disposed on a rack that indicates thelocation of a rack computing unit 20 adjacent that device.

In some embodiments, the rack-mounted computing device 13 is a server(e.g., a computer executing a server application), database, or node ina compute cluster that performs operations requested by users of thedata center 10. Examples include serving webpages, servicing queries,processing API requests, performing simulations, and the like. Suchcomputing operations are distinct from those performed to manage andcontrol the operation of computing devices, for example, by changingversions of operating systems, updating or reconfiguring a BIOS, readingsensors, controlling fans, monitoring thermals, and the like.

In the illustrated embodiment, each rack-mounted computing device 13includes persistent memory 40, a processor 42, dynamic memory 44, and anin-band network interface 46. In some embodiments, these components maybe accessed by the microcontroller 38 via a system management bus 48 orvarious other onboard buses. In some embodiments, the components 40, 42,44, and 46 may reside on a single monolithic motherboard, connected viasoldered connections and conductive traces in a printed circuit board.In some embodiments, the persistent memory 40 is flash memory havingvarious values by which the rack-mounted computing device 13 isconfigured, for example, by changing settings in a BIOS. In someembodiments, the processor 42 is one or more central processing units orgraphics processing units. In some embodiments, the dynamic memory 44contains memory used by the operating system and applications, in somecases having an address space distinct from the computing devices ofother rack computing units.

In some embodiments, the in-band network interface 46 is an Ethernetnetwork interface operable to communicate on a distinct Ethernet networkfrom the networks 16 and 17. Separating these networks is expected tomake the data center 10 more robust to attacks and facilitate operationseven when the in-band network is disabled. Further, in some cases, thein-band network may be substantially higher bandwidth and use moreexpensive equipment than the out-of-band management networks 17 and 16.In some embodiments, the network 15 connected to interface 46 may conveythe data upon which the applications operate, for example, at therequest of users of the data center 10.

FIG. 2 another embodiment of a data center 27 having the featuresdescribed above, except that the out-of-band network 17 extends to therack-mounted computing devices 13. Thus, the rack controller 24communicates with rack-mounted computing devices 13 directly, via theout-of-band network 17, rather than via the powerline communicationnetwork. In other embodiments, a separate Ethernet network specific tothe rack is implemented in place of the power line network describedabove. In this example, the rack-mounted computing devices 13 mayinclude an out-of-band network interface 29 with which the computingdevice 13 communicates with the rack controller 24. In some embodiments,each computing device 13 may include a baseboard management controllerthat communicates with the rack controller 24 via the out-of-and networkinterface 29. In some cases, an Intelligent Platform ManagementInterface (IPMI) API supported by the BMC may expose various functionsby which the rack controller 24 takes inventory of devices onmotherboards of the computing devices 13, read values from sensors (liketemperature sensors), reads values of registers and configures andchanges these values, in some cases, changing settings including EFIsettings. In some embodiments, the BMC is a separate processor fromprocessor 42 executing and in-band application, and the BMC communicateswith various devices on the motherboard via the SMbus.

FIG. 3 shows another embodiment of a data center 51 in which theabove-described rack controller is executed by one of the rack-mountedcomputing devices 31 (which may otherwise have the features of device 13described above). In some cases, software instructions to implement therack controller 33 may be stored in memory 40 and executed by processor42 of the rack-mounted computing device 31. In some cases, the rackcontroller 33 may be executed in a dedicated virtual machine,microkernel, or container of the rack-mounted computing device 31, withother instances of these computing constructs executing otherapplications, in some cases executing in-band applications. In someembodiments, one rack controller 33 may be executed by one (e.g., oneand only one) rack-mounted computing device on a given rack to monitorother rack-mounted computing devices 13 on that rack 12. Or multipleinstances per rack may be executed. Again, in this example, theout-of-band network 17 may extend to the rack-mounted computing devices13 and 31, in some cases without passing through a power linecommunication network.

FIG. 4 shows another embodiment of a data center 35 in which the presenttechniques may be implemented. In this example, the rack controller 37(e.g., having the features of the rack controllers described above) maybe executed by one of the rack-mounted computing devices 41 (otherwisehaving the features of device 13 above), by executing corresponding codein persistent memory 40 with a processor 42, in some cases within adedicated virtual machine, container, or microkernel, e.g., in thearrangement described above for FIG. 3. In this example, the rackcontroller 37 may communicate with rack controllers on other racks 12via the out-of-band network interface 39 of the rack-mounted computingdevice 41 via the out-of-band network 12. Further, the rack controller37 executed by the rack-mounted computing device 41 may control otherrack-mounted computing devices 13 of the rack 12 via the rack-specificpower line communication network 16 and corresponding instances of thenetwork and power adapter 30 described above.

FIG. 5 illustrates an example of a process 50 that may be performed bysome embodiments of the above-described network and power adapter 30 inrack computing units 20. In some embodiments, steps for performing theprocess 50, or the other functionality described herein, are encoded asinstructions on a tangible, non-transitory, machine-readable media, suchthat when the instructions are read and executed by one or moreprocessors, the associated functionality occurs.

In some embodiments, the process 50 includes receiving, with a givenrack computing unit, direct current power via a DC bus connected to aplurality of rack computing units of a rack and configured to deliver DCpower to the plurality of rack computing units, as indicated by block52.

In some embodiments, the process 50 further includes determining that aduration of time designated for the given rack computing unit to accessthe DC power bus for transmission is occurring, as indicated by block54. Next, in response to the determination, some embodiments may apply atime-varying electrical stimulus to the DC power bus, as indicated byblock 56. In some cases, the time-varying electrical stimulus encodes anaddress on the DC power bus of a rack controller and a sensormeasurement indicative of operation of the given rack computing unit. Inother cases, the stimulus may encode control signals rather than datasignals. Next, concurrent with applying the time-varying electricalstimulus, some embodiments include filtering voltage fluctuations of theDC power bus resulting from the time-varying electrical stimulus toproduce electric power used by the given rack computing unit, asindicated by block 58. Producing electrical power does not require thatthe power be generated, merely that power obtained from some source beconditioned properly for usage by the rack computing unit.

FIG. 6 is a flowchart of an example of a process 60 that may be executedby one of the above-described rack controllers 24 (executed in variousforms of data center management devices, e.g., rack control units 18 orrack-mounted computing devices 13 executing a rack controller 24) inorder to monitor and otherwise control a subset of a data center (e.g. arack) responsive to commands from other subsets of the data center orthe above-described administrator computing device 25, e.g. beingoperated by an administrator. In some embodiments, the process 60 mayimplement the northbound and southbound APIs described above, forinstance, with the northbound API facing the network 17 and thesouthbound API facing the network 16. In some embodiments, an instanceof the process 60 may be executed by a different computing deviceassociated with each rack 12 shown in FIGS. 1-4. In some embodiments,API requests may be sent from one rack controller 24 to another rackcontroller 24 or from the administrator computing device 25, forinstance. In some embodiments, the process 60 may be executed ongoing,for instance, listening to a port on the out-of-band network interface26 on the out-of-band network 17 and responding to API requests as theyare received. In some embodiments, the process 60 may be part of anevent processing loop in which API requests are handled, in some caseswith a nonblocking server using deferreds.

In some embodiments, the process 60 includes receiving an API requestvia a first out-of-band network, as indicated by block 62. In someembodiments, this API request may be one of the above-describednorthbound API requests received by the rack controllers 18. In someembodiments, the API request is received via an Ethernet network that isdistinct from the in-band network described above, or some embodimentsmay receive the API requests from the in-band network in cases in whichthe networks have been consolidated. In some embodiments, the APIrequest is a REST-based request encoded in hypertext transport protocol(HTTP), for instance as a POST or GET request received by a serverexecuted by the rack controller 24 described above. Some embodiments mayparse received requests and take responsive action, for instance, via acommon Gateway interface (CGI) routine. In some cases, requests maycontain both commands and parameters of those commands, for instance,separated from the command with the delimiter like “?” and havingkey-value pairs. In some cases, these parameters may specify aparticular device, such as a particular rack-mounted computing device ona rack, or in some cases, these parameters may specify various otherattributes by which actions are taken. Using a REST-based API, with HTTPformatted exchanges, over an Ethernet-implemented IP network, isexpected to facilitate reuse of other tools built for the data centerecosystem, thereby lowering costs and providing a relativelyfeature-rich implementation, though it should be noted that embodimentsare not limited to systems providing these benefits or implementingthese protocols, which is not to imply that any other feature islimiting in all embodiments.

Next, some embodiments may select, based on the API request, a routineto control rack-mounted computing devices, as indicated by block 64.Control may include reading data from such devices or associated sensorsor actuators either on the rack-computing devices or on the rack itself,whether associated with a specific rack-mounted computing device or withthe rack generally. Control may also include sending commands to writeto, reconfigure, or otherwise actuate such devices, for instance, inaccordance with the routines described herein, and including instructingcomputing devices to power cycle, updating firmware in rack-mountedcomputing devices or the various sensors or actuators, reconfiguringfirmware or EFI settings, actuating fans, solenoids, electromagnets,lights, and the like. In some embodiments, the routine is selected basedon text parsed from the API request, and in some embodiments, theroutine is a script selected by a server that received the API requestexecuted by a rack-controller 24. In some embodiments, selecting theroutine includes calling the routine with parameters parsed from the APIrequest as arguments in the function call.

In some embodiments, selecting a routine may include selecting a routinethat takes action via a different network from the network with whichthe API request was received. In some cases, this different network maybe a powerline communication network like those described above withreference to FIGS. 1, 4, and 5, but embodiments are consistent withother implementations, e.g., like those in FIGS. 2 and 3. For instance,in some cases, the other network is a network implemented with Ethernet,RS-232, USB, and the like. Or in some embodiments, the other network isthe same, for instance, a branch of the network with which the APIrequest is received. In some cases, this other network connects to eachof a plurality of computing devices on the rack and various sensors andactuators associated with the rack, for instance, in accordance with thetechniques described above with reference to network 16 in FIG. 1.

In some embodiments, selecting a routine includes selecting a routinethat reads a sensor via the other network on one or more of therack-mounted computing devices. In some cases, this may include sendinga command to the above-described network and power adapters 30 thatcause the above-described microcontroller 38 to query sensor data via anSMbus 48 (as shown in FIG. 1). In some cases, the sensor is on amotherboard or a chassis of the rack computing unit 20 described above,for instance sharing an output of the low-pass DC filter 34 describedabove with the rack-mounted computing unit 13 (as shown in FIG. 1).

In some embodiments, the routine selected is a routine that reads asensor via the other network on the rack. In some embodiments, thesensor is not itself mounted to a rack control unit or powered by anoutput of a specific low-pass DC filter of a rack computing unit 20. Forinstance, some embodiments may read a value from a sensor on a rack thatmeasures temperature, humidity, airflow, vibration, or particles, andopen or close a lock state of a lock for a door or drawer, or the like.In some cases, the sensor is a sensor that reads and identifierindicative of the location of a given computing device in the rack, inaccordance with the techniques described above.

In some embodiments, reading a value from a sensor may includeprocessing that value before sending a response to the API request onthe network 17 described above. Processing may take various forms,depending upon the embodiment and may include, in some cases, convertingan electrical property, like resistance, capacitance, inductance,current, frequency, or voltage, to some other physical propertycorrelated with the electrical property. For example, some embodimentsmay convert one or more of these values into units of temperature (likedegrees Celsius or Fahrenheit), into units of humidity, into units ofvibration (e.g. RPMs), into Boolean values indicating whether doors areopen or closed locked or unlocked, and the like. In some cases,processing may include combining readings from multiple sensors orcombining readings from a given sensor over time, for instance,selecting a largest or smallest value, calculating statistics on thesensor output like standard deviation or mean, and comparing sensorreadings (such as these statistics) to various thresholds, for instance,to determine whether to respond with an alarm or emit an alarm even inthe absence of a recent API request when a reading is above or below athreshold.

In some embodiments, the routines may be selected based on a scheduledAPI request (including an internal API request obtained via a loopbackIP address) rather than a user-driven API request, for instanceaccording to a cron process run by the rack controller to periodicallyread values from sensors and compare those values thresholds formonitoring purposes or logging those values and reporting those valuesto the data center management computing device 25. Or in some cases,these periodic requests may be received from a corresponding processthat periodically automatically sends API requests from theadministrator computing device 25 for monitoring purposes, for instanceto update a dashboard. In either case, the request initiating action maystill be an API request, such as one sent to a loopback address on anetwork interface coupled to the network 17 described above.

In some embodiments, the routine may be a routine that scans electronicdevices on the second network and produces an inventory of theelectronic devices on that network, such as computing devices, sensors,and actuators on the powerline communication network 16 described aboveor computing devices on an SMbus 48 described above.

In some embodiments, the routine may be a routine that changes aconfiguration of an EFI of a given one of the rack-mounted computingdevices, for instance one that changes the same configuration on each ofthe rack-mounted computing devices. For example, some embodiments maychange a boot target of the EFI, such that when the rack-mountedcomputing device is power cycled (or otherwise rebooted), thecorresponding processor may look to a different media indicated by thenew boot target when loading an operating system.

Some embodiments may send operating system updates to the rackcontroller, which may store those operating up system updates on aninstance of this alternate media (such as a different disk drive,solid-state drive, or the like) on each of the rack-mounted computingdevices before changing a boot target on each of those computing devicesand commanding the computing devices to reboot to implement the newoperating system with a reboot. In another example, some embodiments mayupdate applications in this fashion, for instance by downloading animage of a new operating system or container with the new version of anapplication to alternate media and then changing the boot target to thatalternate media. In some cases, these changes may be effectuated withoutinterfacing with an operating system of the computing device 13receiving the change. Similar techniques may be used to update firmwareof peripheral devices.

Next, some embodiments may execute the selected routine, as indicated byblock 66. In some embodiments, the routine may be executed by the rackcontroller described above. In some embodiments, this may includesending a sequence of commands via the second network, such as network16 described above, and in some cases, these commands may be received bythe network and power adapters 30, which may respond by executing theirown routines with microcontroller 38 to effectuate various actions viathe SMbus 48 or other interfaces. In other examples, the above-describedsensors 21 or actuators 23 may receive the corresponding commands viathe network 16 (which again, maybe a powerline communication network orother form of network), and the functionality described above may beimplemented at the direction of a rack controller 24. In the course ofexecuting the routine, some embodiments may send commands via a secondout-of-band network to effectuate an action indicated by the APIrequest, as indicated by block 68. For instance, the routine may includea query for values in registers of computing devices (or componentsthereof) or an inventory of such devices or components. Or the routinemay include instructions to change a configuration of these devices, orread a sensor, or actuate an actuator. Other examples are describedabove. The routine may include operations that cause these commands tobe sent and responses to be processed, consistent with the approachesdescribed above.

In some embodiments, the rack controller 24 may perform agentlessmonitoring of the rack-mounted computing devices 13 via the networks 16and 48 described above. For example, some embodiments may read variousvalues indicative of the performance of the computing device, liketemperature, processor utilization, fan speed, memory utilization,bandwidth utilization on the in-band network 15, packet loss on thein-band network 15, storage utilization, power utilization, and thelike. In some cases, these values may be read from registers associatedwith the corresponding electronic devices without interfacing with anoperating system of the corresponding rack-mounted computing device 13,in some cases via a BMC using the IPMI protocol. Or, in some cases,these values, and the other values read and actions taken, may beeffectuated without using a BMC of the rack-mounted computing devices.

FIGS. 7 and 8 depict techniques implemented in a system referred to as“Vapor Crate” for container, configuration, and file management forserver/workload orchestration/ automation.

In some embodiments of a collection of racks, such as a Vapor chamberdescribed by the documents incorporated by reference, there are sixwedges (each being a rack), where each wedge contains a Vapor EdgeController (VECs) (or other type of rack control unit, like thosedescribed above, which may be dedicated computers coupled to a rackexecuting software to manage and monitor rack-mounted devices, likeservers, or may be executed by the rack-mounted computing devices), usedto host Vapor software such as Vapor CORE. The problem of how toconfigure and manage a large number of VECs (e.g., the rack controllersabove) while reducing the amount of human intervention is worthaddressing, as it may be difficult to manage all of the rack controlunits in a larger data center. In some cases, centralized management maypresent challenges. Relatively expensive, powerful computing equipmentmay be required for management tasks as the number of devices in a datacenter scales. Thus, at commercially relevant scales, computationalresources may impose constraints, in addition to or independent ofconstraints imposed by out-of-band management networks, particularlywhen relatively large machine images, OS updates, and container imagesare distributed to a relatively large number of computing devices. Thatsaid, some embodiments may have a centralized control architecture, asthe various other inventions described herein may also benefit suchsystems.

To mitigate some or all of these issues and others, in some embodiments,an autonomous management system called “Vapor Crate” (or Crate) isprovided. Vapor Crate may carry out some or all of the following tasks:

Service discovery, file and configuration synchronization (e.g., with asystem referred to as “Forklift”)

Physical/logical mapping of management components based on role (e.g.,with a system referred to as “Manifest”)

Device (VEC) bootstrap (Forklift/bootstrap)

Configuration management (Manifest)

File management (Manifest)

Container management (e.g., with a system referred to as “Dockworker”)

OS update management (e.g., with a system referred to as “Hoist”)

UI Management (e.g., with Control Panel)

Crate may be implemented as a set of microservices, distributed acrossthe rack controllers or VECs in a data center. The architectureparallels best practices in the data center industry surroundingfault-expectancy, redundancy, replication, security, configurationmanagement, and decentralization. (Though embodiments are not limited tosystems that implement best practices, which is not to imply that anyother feature is limiting in all cases.) A feature of someimplementations of Crate is to remain fully available to survivingequipment in the event of a large-sale system failure (e.g. power outagein part of a data center in which a device previously having aleadership role in Crate is taken offline). Another feature of someimplementations is the ability to contain network traffic to a localbranch of the data center management network, as the transfer of datainvolved with such an endeavor can be non-trivial. Finally, a feature ofsome implementations is a self-managing system that lowered operationalcost by reducing or eliminating the need for operator intervention inmanaging hardware-management related software in a data center.

Vapor Crate, in some cases, includes service discovery and the abilityto synchronize files and configuration. These capabilities may beprovided by “Forklift”, a service that is included with rack controllersor VECs (e.g., as part of the program code) that discovers or isconfigured with the optimal (e.g., a local or global optimum) “leader”,which serves as the “master” for a given chamber (or other collection orracks). In some embodiments, the “leader” runs a redundant copy of allof the services listed above, typically within the scope of a singleVapor chamber or group of racks—the leader's services are synchronizedto a “primary” rack controller or VEC, designated by consensus in thedata center by the population of leaders. Updates may be made throughthe primary rack controller or VEC, and may be replicated to the leadersin the management unit. In case of failure of the ‘primary’, an electionmay be held by the consensus layer to choose a new primary, and theresults of the election may be replicated out to all leaders.

In some cases, Forklift discovers the existing services (including inbootstrap scenarios where a rack controller or VEC is the first to bebrought online in a data center), and discovers its own service profile,which specifies the services the rack controller or VEC is to run (forexample, to serve as a leader, or as an instance running Vapor CORE).The Crate API may be used by Forklift to communicate with Manifest™ toretrieve file and configuration information, and the appropriatecontainers (services) are retrieved from Dockworker™, and are spun upusing docker-compose or similar orchestration tool. When a container isstarted, in some embodiments, the Crate API may also be used within thecontainer to retrieve from Manifest files or configuration informationneeded that is specialized to the VEC itself, allowing for a singleimage to be used, but configured to the needs of each individual rackcontroller or VEC where appropriate.

In some embodiments, OS updates may be provided by Hoist™, a repreproDebian™ repository that may also contain specific package updates (e.g.to Forklift) as well. Hoist may provide a secure Debian™ repository forsoftware, as many data center management networks (e.g., out-of-bandnetworks) do not have outside network access. Additionally, Hoist∩ mayallow for auditing and curation of package updates to suit user needs.In some embodiments, Dockworker™ is included for a similar reason—accessto Docker Hub™ is typically not possible for similar reasons in someimplementations, and Dockworker™ therefore may fill that void, andallows for curation and auditing of packages. That said, otherembodiments may have out-of-band management networks with Internetaccess.

Gatekeeper™ may be used to provide authentication services used tosecure Crate, and may also be used as the authentication service forVapor CORE or other products to provide fine-grained security from asingle secure location.

Manifest may use MongoDB™ as the data store and MongoDB's GridFS forschematized file storage. In some cases, MongoDB also includes aconsensus-based replication back-end that Crate piggybacks for its ownconsensus purposes—providing dual purpose consensus protocol andelections, as well as notification of election results.

The Crate API, in some embodiments, includes a lightweight objectmapping that schematizes and validates object data exchanged between theAPI endpoint and MongoDB™. The API itself is may be implemented as aPython™ library that uses the object mapping to allow for ease of use byAPI consumers by providing a set of standard Python objects that may beexchanged between the API client and the endpoint. The API endpoint maybe a RESTful API backed by Nginx™ and uWSGI, with Flask™ as themicrodevelopment framework. Data may be exchanged in JSON format, andvalidated prior to interacting with the Manifest data store.

Some variations include a hosted management component to Crate, which isa service used to remotely manage Crate and Vapor services remotely,without the need for any customer intervention whatever. Othervariations include interaction with OpenSwitch™ or other NetworkOperating Systems (NOSes), where Crate is used on a switch or as part ofa NOS to perform management capabilities.

The form factor on which Crate runs may vary. In some embodiments, Cratemay be implemented for rack controller or VEC management, or it may beapplied to broader devops or automated systems management tasks.

Thus, some embodiments may implement control and updates at therack-level, in a distributed, concurrent fashion to facilitaterelatively large-scale operations. In some cases, activities specific toa rack can be handled locally at the rack level. To facilitate fan-out,some embodiments may distribute commands (which may include data bywhich the commands are implemented) through a hierarchical treestructure network graph, which in some cases may be established in parton an ad hoc, peer-to-peer, distributed basis. For instance, therack-level may be at a lower level than a Vapor chamber, and someembodiments may distribute one request per chamber, and then thatrequest may be replicated among the racks in that chamber. Examples mayinclude instructions for file and configuration management (e.g.,profiles), which may dictate how containers behave in each rack controlunit. Embodiments may push out something like a service profile thatsays what each controller should be running, e.g., via REST-basedexchange. To this end, for example, embodiments may send that file viaan API to an endpoint, which may be an arbitrarily chosen controller(e.g., with a consensus algorithm). The designated rack control unit maythen internally route that request to the known primary for thereplicated database. The data may then be sent to the primary, whichthen replicates it out to the replicas, e.g., one rack control unit perchamber. Often updates entail applying the same thing to every chamberand every rack, or in some cases updates may designate the set ofconfiguration and file data that is relevant to a particular class ofmachines or servers or racks. The determination to apply the receiveddata may be made at replica or at the primary level.

An example of a profile change is a change in a setting in aconfiguration for a container. To effect the change, some embodimentsmay send instructions to a replica to change the setting and thatsetting may be committed to the database. In some embodiments, otherrack control units may periodically check the designated master forupdates, e.g., with a pull operation every minute, making an API requestto the master requesting needed files. Some embodiments may have onemaster per chamber, and in some of these examples, anything pushed outto the primary gets pushed out to the masters/replicas. In someembodiments, if the primary fails, a new primary may be elected byconsensus among the devices.

When initializing a rack or a data center, files may be distributed in asimilar fashion to updates, with an arbitrarily chosen rack control unitacting as a seed. Upon boot, an initial master controller client thatruns on rack control units may periodically query for updates. A laptopmay be connected and initially be set to be the provisioning unit viathe endpoint running on that particular machine, and other rack controlunit may thereby obtain the files and settings from the laptop acting asa master. Then, some embodiments may change the settings of the chosenrack control unit to act as a master and seed distribution to otherdevices.

In some embodiments, a hierarchy of rack control units may be maintainedto limit the number of participants in a distributed database. Forinstance, some may be designated management units, which may thenreplicate to devices lower in the hierarchy.

In other embodiments, other techniques may be used for configuring rackcontrol units in a data center. For instance, some embodiments may usepeer-to-peer file sharing protocols, like BitTorrent. In someembodiments, device discovery and data routing may be achieved with adistributed hash table algorithm executing on the participating rackcontrol units (or other computers executing a rack controller). Suchtechniques, and those described above, are expected to make distributedcomputing systems run better than centralized management architectures,particularly as the number of nodes in a network scales and the amountof data to be distributed to each node expands. (This should not betaken as a disclaimer, though, of centralized architectures.) Thesetechniques are also applicable to query routing and distributedprocessing. For instance, the commands may take the form of queries orMapReduce functions.

As noted above, in some embodiments, the rack controllers maycommunicate with one another. In some embodiments, the rack controllersmay be updated, configured, monitored, queried, and otherwise accessedvia a peer-to-peer data center management system 70. The illustratedsystem 70 has topology shown in FIG. 7, indicating the way in whichinformation (such as commands, peer-to-peer networking overhead, andquery responses) flows through the management system 70 to manage therack controllers. In some cases, the topology represents connections atthe application layer, which may be built over the network layertopology described above with reference to FIGS. 1-4. As discussedabove, in some cases, the rack controllers are executed by dedicatedcomputing devices associated with racks, or in some cases byrack-mounted computing devices to execute in band applications. In someembodiments, the illustrated topology may be formed by the rackcontrollers, using a peer-to-peer consensus protocol described below. Insome embodiments, the topology may be a structured topology, such as atree topology like that shown in FIG. 7, or in other embodiments, thetopology may be an unstructured topology, e.g., in other forms of meshtopologies.

In some embodiments, the illustrated system may be relatively robust tofailure by one member of the system, for instance, by one of the rackcontrollers. In some embodiments, for certain operations, remaining rackcontrollers may detect the failure of a given rack controller andcontinue operation, designating other rack controllers fill a rolepreviously performed by a failed rack controller if that rack controllerhad a role significant to other parts of the system 70. In some cases,this may be accomplished with various consensus algorithms executed in adistributed fashion as described below with reference to FIG. 8, such asa leader-based consensus algorithm or a consensus algorithm that doesnot rely on a leader. Examples include the Raft consensus algorithmdescribed in Ongaro, Diego; Ousterhout, John (2013). “In Search of anUnderstandable Consensus Algorithm” (the contents of which are herebyincorporated by reference), and the Paxos consensus algorithm describedin Lamport, Leslie (May 1998). “The Part-Time Parliament” (PDF). ACMTransactions on Computer Systems 16, 2 (May 1998), 133-169 (the contentsof which are hereby incorporated by reference), among others. Incontrast, systems with rigid, predefined, unchangeable roles may berelatively sensitive to failure by any one computing device, as oftenthose systems require human intervention to replace that one computingdevice or otherwise reconfigure the system. In contrast, someembodiments may be fault tolerant and resilient to failures by computingdevices, applications therein, and network. That said, embodiments arenot limited to systems that afford these benefits, as there are variousindependently useful techniques described herein, some of which are notbased on consensus algorithms.

In the illustrated example, the rack controllers are arranged in ahierarchical tree in the topology of the management system 70. In FIG.7, the differing modifiers of “primary” and “lead” should not be takento indicate that, at least in some embodiments, the devices have adifferent architecture. Rather, in some embodiments, each of the devicesillustrated in FIG. 7, in some embodiments, may be a (e.g., identical)instance of a peer rack controller, each controlling a rack in thefashion described above. The lead and primary controllers may be simplydesignated rack controllers that perform additional tasks based on theirrole. The topology may be determined by the rack controllers themselves,dynamically, by executing the routines described below with reference toFIG. 8, in some cases, without a human assigning the roles andarrangement shown in FIG. 7, and with the topology self-evolving to healfrom the failure of devices. In this example, there are three levels tothe topology. At the highest level is a primary rack controller 72. At anext lower level, adjacent the primary rack controller, and therefore indirect communication with the primary rack 72 are lead rack controller74. Three rack controllers 74 are illustrated, but embodiments areconsistent with substantially more, for instance on the order of morethan 50 or more than 500. At the next level of the hierarchy, there area plurality of rack controller 76. Each lead rack controller 74 maycommunicate directly with a plurality of rack controllers 76, in somecases with those rack controllers 76 communicating exclusively with therack controller 74 through the management system 70 or purposes ofmanagement performed by the system 70. In some embodiments, each of therack controllers 76 may control a plurality of rack-mounted computingdevices 78 in the fashion described above. In some embodiments, theillustrated management systems 70 may be implemented in one or more ofthe above-described out-of-band networks. In some embodiments,management system may pass through the illustrated spanning tree, withreplication chaining, thereby distributing communication load across thenetwork and mitigating bottlenecks communication by which rack-mountedcomputing devices, racks, or rack controllers are controlled.

Control may take a variety of different forms. In some embodiments, acommand may be sent by the primary rack controller to update anoperating system of the rack controller or a rack-mounted computingdevice. In some embodiments, command may include an image of anoperating system, in some cases, an image of an operating system, anapplication executed within the operating system, dependencies of thatapplication may be included in the image. In another example, acontainer or microkernel may be configured or provisioned, for instancewith a corresponding disk image stored in, and distributed through, thetopology. In some cases, the command may be sent in sequence ofmessages, some including content by which the command is actuated andother messages including instructions to apply that content.

Other embodiments may include more or fewer levels to the hierarchyillustrated. For example, some embodiments may omit the primary rackcontroller 72, and commands may be distributed via chains spanning treesof the rack controllers 74 to the rack controller 76. Or someembodiments may include additional levels of hierarchy, for instancewith a plurality of primary rack controllers that are adjacent a higherlevel “super-primary” rack controller.

In some embodiments, updates, settings, and other management contentapplied to rack controllers or rack-mounted computing devices, likeoperating systems, applications, microkernel, containers, configurationfiles, and the like they be stored in a distributed repository, such asa distributed file system, or a distributed document database. In somecases, a distributed repository may have a topology that mirrors that ofthe illustrated management system 70. For example, some embodiments mayimplement the MongoDB™ document database, in some cases with theillustrated topology within the database and content be replicatedacross multiple instances illustrated containers, thereby providingredundancy, fault tolerance, data storage, as well as managementcapabilities. Other examples may implement a clustered file system, suchas the InterPlanetary File System as a distributed file system. In someembodiments, the same consensus algorithm by which the management systemdetermines, may be used to determine roles and authoritative copies ofdata in the distributed file system. In some cases, like in leaderlesssystems, roles may correspond to addresses within the topology ofmanagement content.

In some embodiments, the illustrated roles of the different rackcontrollers shown in FIG. 7 implement a distributed consensus protocolexecuted by the rack controllers. In some embodiments, the rackcontrollers may monitor the out-of-band network for a heartbeat signal,for instance in every few seconds, like every two seconds, sent by aleader among a group of rack controllers. Some embodiments may determinethat that heartbeat signal has not been received within a thresholdduration of time and in response initiates an election for a new leader.In some embodiments, each group of rack controllers, for instance, aplurality of 2 to 50, may have one designated leader for the groupthrough which commands are distributed to the group, and through whichinformation about the group is returned up through the illustrated treeof FIG. 7.

Upon determining that no leader heartbeat was received in time, andaction is warranted, a given rack controller making this determinationmay send a message to other rack controllers in the group indicatingthat the given rack controller requests their vote in an election. Insome embodiments, each rack controller may receive this message and todetermine whether to vote for that given rack controller in response.This determination may be based on a variety of differentconsiderations. For instance, each receiving rack controller maydetermine whether the group already has a leader and, in response, senda no vote (or decline to respond). In some embodiments, each receivingrack controller may determine whether the rack controller previouslyvoted an election within less than a threshold duration of time, inwhich case the rack controller may vote no. In some embodiments, eachrack controller may determine whether the rack controller already votedin the current election, in which case the rack controller may vote no.To this end, in some embodiments, when a given rack controller requestsa vote, that rack controller may increment a count that serves as aunique identifier for an election attempt within the group, and otherrack controllers may use this identifier sent with the vote request todetermine whether they have already voted within a given election bylogging their responses in memory and accessing this log to determinewhether they already have a logged vote associated with the electionattempt identifier. In another example, the receiving rack controllermay determine whether the request is the first request received with thegiven election attempt and, in response, return with a yes vote to thefirst request received and a no vote to other requests. In anotherexample, the vote requests may include a value indicative of a versionof data stored in a distributed file system by the requesting rackcontroller, and receiving rack controllers may determine whether to votefor that rack controller based on whether they store a more up-to-dateversion or based on whether another rack controller has requested a votewith a more up-to-date version.

In some embodiments, each rack controller may send a heartbeat signalperiodically, like every two seconds, to every rack controller in therespective group, and every rack controller in the group may receivethese heartbeat signals and maintain a list of rack controller in thegroup. Based on this list, the rack controller requesting a vote mayreceive votes in its favor and determine whether more than a majority ofvotes in favor have been received by counting votes received andcomparing the count to a threshold that is half the number of uniqueheartbeat signals received from members of the group. Upon receiving amajority of votes, and determining this to be the case, a given rackcontroller may determine that it has taken the role of a leader,communicate this to the group, and other rack controllers in the groupmay look to that rack controller as filling the role of leader.

Once leaders for each group are determined, in some cases, those leadersmay determine the primary rack controller with a similar technique, withthe leaders serving as the group in electing a member of the group tooperate as a primary rack controller.

In some embodiments, the time thresholds for determining whether a givenrack controller has failed may be adjusted according to a random value.Randomizing the threshold is expected to reduce the likelihood thatdifferent rack controllers call for elections concurrently with thegroup, thereby reducing the likelihood of tie elections delayed electionresults causing an election to be re-run.

At various times, various rack controllers filling various roles mayfail. Failure does not require that the computing device ceaseoperation, merely that the rack controller be perceived by other rackcontrollers to not perform at least part of the function correspondingto the role held by the rack controller. Examples include failure tosend a heartbeat signal, or failure to send a command or otherinformation through the topology 70 shown in FIG. 7 within a (e.g.,randomized, like pseudorandomized) threshold duration of time. In somecases, durations of time since the last signal was received may serve asa health score for each rack controller, and these health scores may bepropagated through the management system 70 according to the illustratedtopology, with a given rack controller reporting health scores for thosebelow it, and advancing those health scores upward, while distributinghealth scores for those upward to those below. This is expected to scalebetter relative to systems that implement a fully connected graph,though embodiments are also consistent with this approach.

FIG. 8 shows an example of a process 80 by which roles may be determinedand management may be effectuated within a data center managementsystem, such as that described above with reference to FIG. 7. In someembodiments, the process 80 includes determining a leader rackcontroller among a group a rack controllers, as indicated by block 82.In some cases, this operation may be performed when initializing a datacenter or in response to determining that a given previous leader rackcontroller is not responding. In some embodiments, determining a leadermay include determining a leader through the techniques described abovewith a distributed consensus protocol, with a plurality of rackcontrollers with a group communicating with one another in order toselect a leader (or primary) and arriving at a consensus regarding theselection.

Next, some embodiments may determine whether threshold duration haselapsed to receive a periodic signal (or other signal) from the leader,as indicated by block 84. In some cases, this may be receiving aheartbeat signal, or in some cases this may include a poor request, suchas a request for a response indicating the help of the leader. In somecases, block 82 may be done in a distributed fashion by the group, whileblock 84 may be performed by each member of the group. Similarly, eachmember of the group may determine in response to the time elapsing inblock 84 whether the leader is still operative, as indicated by block86. As noted above, an inoperative leader may still be functioning, butnot filling a portion of the role in the system, for instance in theevent of a network failure. If the leader is not operative, someembodiments may determine a new leader rack controller and return toblock 82, using the techniques described above.

If the leader is operative, some embodiments may determine whether thereis a new command from the leader, as indicated by block 88. In somecases, the command may be a series of messages, such as a messageinstructing rack mounting computing device to retrieve informationstored in a distributed file system, like an application update,descriptions of changing configurations, a container image, a diskimage, and the like, and apply that management content to a respectiverack controller with the command. In another example, the command may bea query to downstream rack controllers or a query to be translated andsent to downstream rack-mounted computing devices, for instance, withthe techniques described above.

Upon determining that there are no commands, some embodiments may returnto before block 84 and continue to wait for when for a periodic checkthat the leader is operative. In some cases, messages may be receivedbetween periodic heartbeats, for instance, with commands.

Upon determining that there is a new command, some embodiments maydistribute the commands to the rack controllers under the respectiveleader. In some embodiments, these operations 82 through 90 may beexecuted concurrently, asynchronously, by a plurality of differentgroups within the data center, in some cases, with different groupsselecting the leaders at different times.

In another example of a concurrent operation in some embodiments, upondetermining a leader for the rack controller among a group rackcontrollers, each rack controller may determine whether it is itself aleader, as indicated by block 92. This concurrent branch may end whenthe answer is no. Those rack controllers that determine that they havebeen elected the leader, may proceed to block 94, in which the leaderrack controllers may each determine whether there is a primary rackcontroller that is operative, as indicated by block 94. Thisdetermination may be similar to that of block 86 described above, withthe group of leaders serving as the relevant group. Upon determiningthat the leader is not operative, some embodiments may determine aprimary rack controller among the leader rack controllers, as indicatedby block 96. This operation may include executing one or more of theabove-described consensus protocols on the various leader rackcontrollers to elect a primary rack controller. Next, some embodimentsmay determine whether the time has arrived for a periodic check, asindicated by block 98. If the answer is no, some embodiments maycontinue waiting, or if the answer is yes, some embodiments may returnto block 94 and determine whether the primary rack controllers stilloperative. If the primary rack controller is determined to be operative,some embodiments may determine whether there is new command from theprimary rack, as indicated by block 100. Again, this operation mayinclude the operations described above with respect to block 88, exceptfrom the perspective of a leader. The operations of blocks 98, 94, and100 may be performed by each leader rack controller concurrently andasynchronously, and the operation of block 96 may be performedcollectively by the leader rack controllers. Upon determining that thereis no new command, some embodiments may return to block 98 and continuewaiting for a periodic check or new command.

In some cases, new commands may be pushed, without waiting to make adetermination whether a new command is available. Upon determining thata new command is available, some embodiments may distribute the commandto the leader rack controllers, as indicated by block 102. Thisoperation may include the operations described above with reference toblock 90, except from the perspective of leader rack controller. Thedistribution of block 102 may cause a positive response in thedetermination of block 88 above. Thus, new commands may be fanned outthroughout a topology of rack controllers without forming a bottleneckat any one rack controller, and the distribution may be accomplished ina way that is relatively fault-tolerant to the failure of any one rackcontroller of the data center management system 70. In some embodiments,the content by which the commands are implemented, which may includerelatively large files including operating systems, containers,applications, dependencies, and configuration settings, may bedistributed in the same or a similar fashion, thereby also distributingthe relatively bandwidth heavy load throughout the data center andavoiding bottlenecks, while also remaining resilient to failures. Again,it should be noted that several inventions are described, and thoseinventions may be viewed independently, so these benefits may not beafforded by all embodiments consistent with the present description.

FIG. 9 is a diagram that illustrates an exemplary computing system 1000in accordance with embodiments of the present technique. In some cases,each rack of the above-described racks may house one or more of thesesystems 1000. Various portions of systems and methods described herein,may include or be executed on one or more computer systems similar tocomputing system 1000. Further, processes and modules described hereinmay be executed by one or more processing systems similar to that ofcomputing system 1000.

Computing system 1000 may include one or more processors (e.g.,processors 1010 a-1010 n) coupled to system memory 1020, an input/outputI/O device interface 1030, and a network interface 1040 via aninput/output (I/O) interface 1050. A processor may include a singleprocessor or a plurality of processors (e.g., distributed processors). Aprocessor may be any suitable processor capable of executing orotherwise performing instructions. A processor may include a centralprocessing unit (CPU) that carries out program instructions to performthe arithmetical, logical, and input/output operations of computingsystem 1000. A processor may execute code (e.g., processor firmware, aprotocol stack, a database management system, an operating system, or acombination thereof) that creates an execution environment for programinstructions. A processor may include a programmable processor. Aprocessor may include general or special purpose microprocessors. Aprocessor may receive instructions and data from a memory (e.g., systemmemory 1020). Computing system 1000 may be a uni-processor systemincluding one processor (e.g., processor 1010 a), or a multi-processorsystem including any number of suitable processors (e.g., 1010 a-1010n). Multiple processors may be employed to provide for parallel orsequential execution of one or more portions of the techniques describedherein. Processes, such as logic flows, described herein may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating corresponding output. Processes described herein may beperformed by, and apparatus can also be implemented as, special purposelogic circuitry, e.g., an FPGA (field programmable gate array) or anASIC (application specific integrated circuit). Computing system 1000may include a plurality of computing devices (e.g., distributed computersystems) to implement various processing functions.

I/O device interface 1030 may provide an interface for connection of oneor more I/O devices 1060 to computer system 1000. I/O devices mayinclude devices that receive input (e.g., from a user) or outputinformation (e.g., to a user). I/O devices 1060 may include, forexample, graphical user interface presented on displays (e.g., a cathoderay tube (CRT) or liquid crystal display (LCD) monitor), pointingdevices (e.g., a computer mouse or trackball), keyboards, keypads,touchpads, scanning devices, voice recognition devices, gesturerecognition devices, printers, audio speakers, microphones, cameras, orthe like. I/O devices 1060 may be connected to computer system 1000through a wired or wireless connection. I/O devices 1060 may beconnected to computer system 1000 from a remote location. I/O devices1060 located on remote computer system, for example, may be connected tocomputer system 1000 via a network and network interface 1040.

Network interface 1040 may include a network adapter that provides forconnection of computer system 1000 to a network. Network interface may1040 may facilitate data exchange between computer system 1000 and otherdevices connected to the network. Network interface 1040 may supportwired or wireless communication. The network may include an electroniccommunication network, such as the Internet, a local area network (LAN),a wide area network (WAN), a cellular communications network, or thelike.

System memory 1020 may be configured to store program instructions 1100or data 1110. Program instructions 1100 may be executable by a processor(e.g., one or more of processors 1010 a-1010 n) to implement one or moreembodiments of the present techniques. Instructions 1100 may includemodules of computer program instructions for implementing one or moretechniques described herein with regard to various processing modules.Program instructions may include a computer program (which in certainforms is known as a program, software, software application, script, orcode). A computer program may be written in a programming language,including compiled or interpreted languages, or declarative orprocedural languages. A computer program may include a unit suitable foruse in a computing environment, including as a stand-alone program, amodule, a component, or a subroutine. A computer program may or may notcorrespond to a file in a file system. A program may be stored in aportion of a file that holds other programs or data (e.g., one or morescripts stored in a markup language document), in a single filededicated to the program in question, or in multiple coordinated files(e.g., files that store one or more modules, sub programs, or portionsof code). A computer program may be deployed to be executed on one ormore computer processors located locally at one site or distributedacross multiple remote sites and interconnected by a communicationnetwork.

System memory 1020 may include a tangible program carrier having programinstructions stored thereon. A tangible program carrier may include anon-transitory computer readable storage medium. A non-transitorycomputer readable storage medium may include a machine readable storagedevice, a machine readable storage substrate, a memory device, or anycombination thereof. Non-transitory computer readable storage medium mayinclude non-volatile memory (e.g., flash memory, ROM, PROM, EPROM,EEPROM memory), volatile memory (e.g., random access memory (RAM),static random access memory (SRAM), synchronous dynamic RAM (SDRAM)),bulk storage memory (e.g., CD-ROM or DVD-ROM, hard-drives), or the like.System memory 1020 may include a non-transitory computer readablestorage medium that may have program instructions stored thereon thatare executable by a computer processor (e.g., one or more of processors1010 a-1010 n) to cause the subject matter and the functional operationsdescribed herein. A memory (e.g., system memory 1020) may include asingle memory device or a plurality of memory devices (e.g., distributedmemory devices).

I/O interface 1050 may be configured to coordinate I/O traffic betweenprocessors 1010 a-1010 n, system memory 1020, network interface 1040,I/O devices 1060, or other peripheral devices. I/O interface 1050 mayperform protocol, timing, or other data transformations to convert datasignals from one component (e.g., system memory 1020) into a formatsuitable for use by another component (e.g., processors 1010 a-1010 n).I/O interface 1050 may include support for devices attached throughvarious types of peripheral buses, such as a variant of the PeripheralComponent Interconnect (PCI) bus standard or the Universal Serial Bus(USB) standard.

Embodiments of the techniques described herein may be implemented usinga single instance of computer system 1000 or multiple computer systems1000 configured to host different portions or instances of embodiments.Multiple computer systems 1000 may provide for parallel or sequentialprocessing/execution of one or more portions of the techniques describedherein.

Those skilled in the art will appreciate that computer system 1000 ismerely illustrative and is not intended to limit the scope of thetechniques described herein. Computer system 1000 may include anycombination of devices or software that may perform or otherwise providefor the performance of the techniques described herein. For example,computer system 1000 may include or be a combination of acloud-computing system, a data center, a server rack, a server, avirtual server, a desktop computer, a laptop computer, a tabletcomputer, a server device, a client device, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a vehicle-mounted computer, or a Global Positioning System(GPS), or the like. Computer system 1000 may also be connected to otherdevices that are not illustrated, or may operate as a stand-alonesystem. In addition, the functionality provided by the illustratedcomponents may in some embodiments be combined in fewer components ordistributed in additional components. Similarly, in some embodiments,the functionality of some of the illustrated components may not beprovided or other additional functionality may be available.

Those skilled in the art will also appreciate that while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described above. Insome embodiments, instructions stored on a computer-accessible mediumseparate from computer system 1000 may be transmitted to computer system1000 via transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network or a wireless link. Various embodiments may furtherinclude receiving, sending, or storing instructions or data implementedin accordance with the foregoing description upon a computer-accessiblemedium. Accordingly, the present invention may be practiced with othercomputer system configurations.

The reader should appreciate that the present application describesseveral inventions. Rather than separating those inventions intomultiple isolated patent applications, applicants have grouped theseinventions into a single document because their related subject matterlends itself to economies in the application process. But the distinctadvantages and aspects of such inventions should not be conflated. Insome cases, embodiments address all of the deficiencies noted herein,but it should be understood that the inventions are independentlyuseful, and some embodiments address only a subset of such problems oroffer other, unmentioned benefits that will be apparent to those ofskill in the art reviewing the present disclosure. Due to costconstraints, some inventions disclosed herein may not be presentlyclaimed and may be claimed in later filings, such as continuationapplications or by amending the present claims. Similarly, due to spaceconstraints, neither the Abstract nor the Summary of the Inventionsections of the present document should be taken as containing acomprehensive listing of all such inventions or all aspects of suchinventions.

It should be understood that the description and the drawings are notintended to limit the invention to the particular form disclosed, but tothe contrary, the intention is to cover all modifications, equivalents,and alternatives falling within the spirit and scope of the presentinvention as defined by the appended claims. Further modifications andalternative embodiments of various aspects of the invention will beapparent to those skilled in the art in view of this description.Accordingly, this description and the drawings are to be construed asillustrative only and are for the purpose of teaching those skilled inthe art the general manner of carrying out the invention. It is to beunderstood that the forms of the invention shown and described hereinare to be taken as examples of embodiments. Elements and materials maybe substituted for those illustrated and described herein, parts andprocesses may be reversed or omitted, and certain features of theinvention may be utilized independently, all as would be apparent to oneskilled in the art after having the benefit of this description of theinvention. Changes may be made in the elements described herein withoutdeparting from the spirit and scope of the invention as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if X, Y,”“when X, Y,” and the like, encompass causal relationships in which theantecedent is a necessary causal condition, the antecedent is asufficient causal condition, or the antecedent is a contributory causalcondition of the consequent, e.g., “state X occurs upon condition Yobtaining” is generic to “X occurs solely upon Y” and “X occurs upon Yand Z.” Such conditional relationships are not limited to consequencesthat instantly follow the antecedent obtaining, as some consequences maybe delayed, and in conditional statements, antecedents are connected totheir consequents, e.g., the antecedent is relevant to the likelihood ofthe consequent occurring. Statements in which a plurality of attributesor functions are mapped to a plurality of objects (e.g., one or moreprocessors performing steps A, B, C, and D) encompasses both all suchattributes or functions being mapped to all such objects and subsets ofthe attributes or functions being mapped to subsets of the attributes orfunctions (e.g., both all processors each performing steps A-D, and acase in which processor 1 performs step A, processor 2 performs step Band part of step C, and processor 3 performs part of step C and step D),unless otherwise indicated. Further, unless otherwise indicated,statements that one value or action is “based on” another condition orvalue encompass both instances in which the condition or value is thesole factor and instances in which the condition or value is one factoramong a plurality of factors. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.

The present techniques will be better understood with reference to thefollowing enumerated embodiments:

1. A method of managing rack-mounted computing devices in a data centerwith a distributed peer-to-peer management system, the methodcomprising: determining roles of data-center management computingdevices in a distributed peer-to-peer data-center management system;receiving, via an out-of-band network, a data-center management commandat a given data-center management computing device; distributing, basedon at least some of the roles, via the out-of-band network, thedata-center management command from the given data-center managementcomputing device to a first plurality of other data-center managementcomputing devices; and for each of the first plurality of otherdata-center management computing devices, distributing, based at leastsome of the roles, via the out-of-band network, the data-centermanagement command to a respective second plurality of other data-centermanagement computing devices, wherein: the given data-center managementcomputing device, the first plurality of other data-center managementcomputing devices, and the respective second pluralities of otherdata-center management computing devices are each configured to manage arespective plurality of rack-mounted computing devices; each of thepluralities of respective rack-mounted computing devices executes anin-band application that communicates on an in-band network differentfrom the out-of-band network; and the data-center management command isa command to update or otherwise configure a microkernel, a virtualmachine, a container, an operating system, or an application executingon one or more data-center management computing devices.

2. The method of embodiment 1, wherein: determining roles of data-centermanagement computing devices in a distributed peer-to-peer data-centermanagement system comprises: selecting a primary data-center managementcomputing device; selecting a plurality of leader data-center managementcomputing devices by concurrently executing a plurality of respectiveinstances of a distributed algorithm by which the respective leader isdetermined by consensus, each instance being executed by one of thesecond pluralities of other data-center management computing devices toselect a respective leader for the respective one of the secondpluralities of other data-center management computing devices.

3. The method of embodiment 3, wherein selecting a plurality of leaderdata-center management computing devices by concurrently executing aplurality of respective instances of a distributed algorithm by whichthe respective leader is determined by consensus comprises: detectingwith a first one of the data-center management computing devices that asignal has not been received from a leader within a threshold durationof time; incrementing or decrementing a count with the with first one ofthe data-center management computing devices; sending, with the firstone of the data-center management computing devices, a request to votefor a new leader along with the incremented or decremented count toother data-center management computing devices in the same secondplurality of other data-center management computing devices; receivingthe request with a second one of the data-center management computingdevices; determining, with the second one of the data-center managementcomputing devices, to vote for the first one of the data-centermanagement computing devices, at least in part, by: determining that thesecond one of the data-center management computing devices has not yetsubmitted a vote associated with the incremented or decremented count;and determining that the request is the first request received by thesecond one of the data-center management computing devices in a givenround of voting; sending, with the second one of the data-centermanagement computing devices, the vote to other data-center managementcomputing devices in the same second plurality of other data-centermanagement computing devices; selecting a leader based on amounts ofvotes received by candidate data-center management computing devices.

4. The method of any one of embodiments 1-3, wherein: determining rolescomprises determining roles in a peer-to-peer distributed applicationhaving a structured topology.

5. The method of embodiment 4, wherein: the structured topology is atree topology having at least three levels, wherein: the givendata-center management computing device is at a first level of the treetopology; the first plurality of other data-center management computingdevices is at a second level of the tree topology, each being adjacentto the given data-center management computing device in the treetopology; the second pluralities of other data-center managementcomputing devices are at a third level of the tree topology, eachrespective plurality of other data-center management computing devicesbeing adjacent to a respective one of the first plurality of otherdata-center management computing devices in the tree topology.

6. The method of any one of embodiments 1-5, wherein: determining rolescomprises determining roles in a peer-to-peer distributed applicationhaving an unstructured topology.

7. The method of any one of embodiments 1-6, comprising: determining,with at least one of the first plurality of other data-center managementcomputing devices, that the given data-center management computingdevice has failed; electing, with at least one of the first plurality ofother data-center management computing devices, one of the firstplurality of other data-center management computing devices to serve asa replacement to the given data-center management computing device in atleast some roles filled by the given data-center management computingdevice; and distributing a result of the election to each the firstplurality of other data-center management computing devices.

8. The method of any one of embodiments 1-7, comprising: obtaining afile with configuration information from a distributed file systemstored with cross-computing-device redundancy by at least a plurality ofthe first plurality of other data-center management computing devices,the second pluralities of other data-center management computingdevices, or both.

9. The method of embodiment 8, wherein: the file is stored withconsensus-based replication based on a consensus protocol, and whereinthe consensus protocol is used to determine at least some roles of thedata center management computing devices.

10. The method of any one of embodiments 1-9, wherein: at least some ofthe data-center management computing devices are a rack controllerexecuted in an out-of-band computer having a processor and memorystoring instructions that when executed effectuate at least some of theoperations of c at least some of the data-center management computingdevices manage rack-mounted computing devices via respective ones of aplurality of different power-line communication networks; and theout-of-band network is a different network from the power-linecommunication networks.

11. The method of any one of embodiments 1-9, wherein: at least some ofthe data-center management computing devices are rack-mounted computingdevices executing a rack controller; and at least some of thedata-center management computing devices manage rack-mounted computingdevices via an Ethernet network, without a power-line communicationnetwork connecting the at least some of the data-center managementcomputing devices to the rack-mounted computing devices.

12. The method of any one of embodiments 1-9, wherein: at least some ofthe data-center management computing devices are a rack-mountedcomputing device executing a rack controller; and at least some of thedata-center management computing devices manage rack-mounted computingdevices via a power-line communication network.

13. The method of any one of embodiments 1-9, wherein: at least some ofthe data-center management computing devices are a rack controllerexecuted in an out-of-band computer having a processor and memorystoring instructions that when executed effectuate at least some of theoperations of embodiment 1; and at least some of the data-centermanagement computing devices manage rack-mounted computing devices via anon-power-line communication network.

14. The method of any one of embodiments 1-13, wherein: at least some ofthe data-center management computing devices execute rack controllers,each configured to manage a plurality of rack-mounted computing deviceson a respective rack, a sensor on the respective rack, and an actuatoron the respective rack, wherein the sensor and actuator are not on achassis of one of the rack-mounted computing devices on the respectiverack, wherein controlling the rack-mounted computing devices comprises:changing a boot target in an extensible firmware interface of a givenone of the rack-mounted computing devices on the respective rack;reading a value indicative of temperature from the sensor or a sensor ofa given one of the rack-mounted computing devices on the respectiverack; and actuating the actuator.

15. The method of any one of embodiments 1-14, wherein: the commandincludes a disk image containing an operating system, an application,and dependencies of the application to be installed on each of the firstdata-center management computing device, the first plurality of otherdata-center management computing devices, and the respective pluralitiesof other data-center management computing devices.

16. The method of any one of embodiments 1-15, wherein: the command is acommand to orchestrate containers executing on at least some of thedata-center management computing devices.

17. The method of any one of embodiments 1-16, wherein: the command is acommand to configure a network operating system.

18. The method of any one of embodiments 1-17, comprising implementingcontrol and updates of rack controllers at the rack-level, in adistributed, concurrent routine.

19. The method of any one of embodiments 1-18, wherein distributing,based at least some of the roles, via the out-of-band network, thedata-center management command to a respective plurality of otherdata-center management computing devices comprises: periodically, byeach of the plurality of other data-center management computing devices,sending a request to one of the plurality of other data-centermanagement computing devices for an update; and receiving an update,from the one of the plurality of other data-center management computingdevices, with each of the plurality of other data-center managementcomputing devices.

20. The method of any one of embodiments 1-19, comprising: initializinga data center with a computer designated to act as a seed unit todistribute configuration files via the given data-center managementcomputing device and the first plurality of other data-center managementcomputing devices.

21. The method of any one of embodiments 1-20, wherein determining rolesof data-center management computing devices in a distributedpeer-to-peer data-center management system comprises: steps for devicediscovery and data routing.

22. The method of any one of embodiments 1-21, comprising: performingsteps for configuring rack control units in a data center.

23. The method of any one of embodiments 1-22, wherein determining rolesof data-center management computing devices in a distributedpeer-to-peer data-center management system comprises: steps for arrivingat a consensus among data-center management computing devices.

24. The method of any one of embodiments 1-23, comprising: executing thein-band application to provide resources to remote computing devicesover the Internet with rack-mounted computing devices controlled by atleast some of the given data-center management computing device, thefirst plurality of other data-center management computing devices, andthe second pluralities of other data-center management computingdevices.

25. A system, comprising: a plurality of racks, each rack comprising: aplurality of rack-mounted computing devices; and a medium storinginstructions configured to instantiate a rack controller coupled to eachof the rack-mounted computing devices via a network, wherein each rackcontroller is configured to effectuate operations comprising:determining roles of the rack controllers in a distributed peer-to-peerdata-center management system; receiving a data-center managementcommand at a first rack controller; distributing, based on at least someof the roles, the data-center management command from the first rackcontroller to a first plurality of other rack controller; and for eachof the first plurality of other rack controllers, distributing, based atleast some of the roles, the data-center management command to arespective plurality of other rack controllers.

26. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by one or more processors effectuateoperations comprising: the operations of any one of embodiments 1-25.

What is claimed is:
 1. A method of managing rack-mounted computingdevices in a data center with a distributed peer-to-peer managementsystem, the method comprising: determining roles of data-centermanagement computing devices in a distributed peer-to-peer data-centermanagement system; receiving, via an out-of-band network, a data-centermanagement command at a given data-center management computing device;distributing, based on at least some of the roles, via the out-of-bandnetwork, the data-center management command from the given data-centermanagement computing device to a first plurality of other data-centermanagement computing devices; and for each of the first plurality ofother data-center management computing devices, distributing, based atleast some of the roles, via the out-of-band network, the data-centermanagement command to a respective second plurality of other data-centermanagement computing devices, wherein: the given data-center managementcomputing device, the first plurality of other data-center managementcomputing devices, and the respective second pluralities of otherdata-center management computing devices are each configured to manage arespective plurality of rack-mounted computing devices; each of thepluralities of respective rack-mounted computing devices executes anin-band application that communicates on an in-band network differentfrom the out-of-band network; and the data-center management command isa command to update or otherwise configure a microkernel, a virtualmachine, a container, an operating system, or an application executingon one or more data-center management computing devices.
 2. The methodof claim 1, wherein: determining roles of data-center managementcomputing devices in a distributed peer-to-peer data-center managementsystem comprises: selecting a primary data-center management computingdevice; selecting a plurality of leader data-center management computingdevices by concurrently executing a plurality of respective instances ofa distributed algorithm by which the respective leader is determined byconsensus, each instance being executed by one of the second pluralitiesof other data-center management computing devices to select a respectiveleader for the respective one of the second pluralities of otherdata-center management computing devices.
 3. The method of claim 3,wherein selecting a plurality of leader data-center management computingdevices by concurrently executing a plurality of respective instances ofa distributed algorithm by which the respective leader is determined byconsensus comprises: detecting with a first one of the data-centermanagement computing devices that a signal has not been received from aleader within a threshold duration of time; incrementing or decrementinga count with the with first one of the data-center management computingdevices; sending, with the first one of the data-center managementcomputing devices, a request to vote for a new leader along with theincremented or decremented count to other data-center managementcomputing devices in the same second plurality of other data-centermanagement computing devices; receiving the request with a second one ofthe data-center management computing devices; determining, with thesecond one of the data-center management computing devices, to vote forthe first one of the data-center management computing devices, at leastin part, by: determining that the second one of the data-centermanagement computing devices has not yet submitted a vote associatedwith the incremented or decremented count; and determining that therequest is the first request received by the second one of thedata-center management computing devices in a given round of voting;sending, with the second one of the data-center management computingdevices, the vote to other data-center management computing devices inthe same second plurality of other data-center management computingdevices; selecting a leader based on amounts of votes received bycandidate data-center management computing devices.
 4. The method ofclaim 1, wherein: determining roles comprises determining roles in apeer-to-peer distributed application having a structured topology. 5.The method of claim 4, wherein: the structured topology is a treetopology having at least three levels, wherein: the given data-centermanagement computing device is at a first level of the tree topology;the first plurality of other data-center management computing devices isat a second level of the tree topology, each being adjacent to the givendata-center management computing device in the tree topology; the secondpluralities of other data-center management computing devices are at athird level of the tree topology, each respective plurality of otherdata-center management computing devices being adjacent to a respectiveone of the first plurality of other data-center management computingdevices in the tree topology.
 6. The method of claim 1, wherein:determining roles comprises determining roles in a peer-to-peerdistributed application having an unstructured topology.
 7. The methodof claim 1, comprising: determining, with at least one of the firstplurality of other data-center management computing devices, that thegiven data-center management computing device has failed; electing, withat least one of the first plurality of other data-center managementcomputing devices, one of the first plurality of other data-centermanagement computing devices to serve as a replacement to the givendata-center management computing device in at least some roles filled bythe given data-center management computing device; and distributing aresult of the election to each the first plurality of other data-centermanagement computing devices.
 8. The method of claim 1, comprising:obtaining a file with configuration information from a distributed filesystem stored with cross-computing-device redundancy by at least aplurality of the first plurality of other data-center managementcomputing devices, the second pluralities of other data-centermanagement computing devices, or both.
 9. The method of claim 8,wherein: the file is stored with consensus-based replication based on aconsensus protocol, and wherein the consensus protocol is used todetermine at least some roles of the data center management computingdevices.
 10. The method of claim 1, wherein: at least some of thedata-center management computing devices are a rack controller executedin an out-of-band computer having a processor and memory storinginstructions that when executed effectuate at least some of theoperations of claim 1; at least some of the data-center managementcomputing devices manage rack-mounted computing devices via respectiveones of a plurality of different power-line communication networks; andthe out-of-band network is a different network from the power-linecommunication networks.
 11. The method of claim 1, wherein: at leastsome of the data-center management computing devices are rack-mountedcomputing devices executing a rack controller; and at least some of thedata-center management computing devices manage rack-mounted computingdevices via an Ethernet network, without a power-line communicationnetwork connecting the at least some of the data-center managementcomputing devices to the rack-mounted computing devices.
 12. The methodof claim 1, wherein: at least some of the data-center managementcomputing devices are a rack-mounted computing device executing a rackcontroller; and at least some of the data-center management computingdevices manage rack-mounted computing devices via a power-linecommunication network.
 13. The method of claim 1, wherein: at least someof the data-center management computing devices are a rack controllerexecuted in an out-of-band computer having a processor and memorystoring instructions that when executed effectuate at least some of theoperations of claim 1; and at least some of the data-center managementcomputing devices manage rack-mounted computing devices via anon-power-line communication network.
 14. The method of claim 1,wherein: at least some of the data-center management computing devicesexecute rack controllers, each configured to manage a plurality ofrack-mounted computing devices on a respective rack, a sensor on therespective rack, and an actuator on the respective rack, wherein thesensor and actuator are not on a chassis of one of the rack-mountedcomputing devices on the respective rack, wherein controlling therack-mounted computing devices comprises: changing a boot target in anextensible firmware interface of a given one of the rack-mountedcomputing devices on the respective rack; reading a value indicative oftemperature from the sensor or a sensor of a given one of therack-mounted computing devices on the respective rack; and actuating theactuator.
 15. The method of claim 1, wherein: the command includes adisk image containing an operating system, an application, anddependencies of the application to be installed on each of the firstdata-center management computing device, the first plurality of otherdata-center management computing devices, and the respective pluralitiesof other data-center management computing devices.
 16. The method ofclaim 1, wherein: the command is a command to orchestrate containersexecuting on at least some of the data-center management computingdevices.
 17. The method of claim 1, wherein: the command is a command toconfigure a network operating system.
 18. The method of claim 1,comprising implementing control and updates of rack controllers at therack-level, in a distributed, concurrent routine.
 19. The method ofclaim 1, wherein distributing, based at least some of the roles, via theout-of-band network, the data-center management command to a respectiveplurality of other data-center management computing devices comprises:periodically, by each of the plurality of other data-center managementcomputing devices, sending a request to one of the plurality of otherdata-center management computing devices for an update; and receiving anupdate, from the one of the plurality of other data-center managementcomputing devices, with each of the plurality of other data-centermanagement computing devices.
 20. The method of claim 1, comprising:initializing a data center with a computer designated to act as a seedunit to distribute configuration files via the given data-centermanagement computing device and the first plurality of other data-centermanagement computing devices.
 21. The method of claim 1, whereindetermining roles of data-center management computing devices in adistributed peer-to-peer data-center management system comprises: stepsfor device discovery and data routing.
 22. The method of claim 1,comprising: performing steps for configuring rack control units in adata center.
 23. The method of claim 1, wherein determining roles ofdata-center management computing devices in a distributed peer-to-peerdata-center management system comprises: steps for arriving at aconsensus among data-center management computing devices.
 24. The methodof claim 1, comprising: executing the in-band application to provideresources to remote computing devices over the Internet withrack-mounted computing devices controlled by at least some of the givendata-center management computing device, the first plurality of otherdata-center management computing devices, and the second pluralities ofother data-center management computing devices.
 25. A system,comprising: a plurality of racks, each rack comprising: a plurality ofrack-mounted computing devices; and a medium storing instructionsconfigured to instantiate a rack controller coupled to each of therack-mounted computing devices via a network, wherein each rackcontroller is configured to effectuate operations comprising:determining roles of the rack controllers in a distributed peer-to-peerdata-center management system; receiving a data-center managementcommand at a first rack controller; distributing, based on at least someof the roles, the data-center management command from the first rackcontroller to a first plurality of other rack controller; and for eachof the first plurality of other rack controllers, distributing, based atleast some of the roles, the data-center management command to arespective plurality of other rack controllers.